Ich bin fertig mit Red Hat (Enterprise Linux)
(jeffgeerling.com)- Jeff Geerling, der auch nach dem Ende von CentOS im Red-Hat-Ökosystem geblieben war, stellt aufgrund der geänderten Zugänglichkeit der RHEL-Quellen die offizielle Unterstützung für Enterprise Linux ein
- Die neue Richtlinie verändert den für RHEL-Rebuilds nötigen Source-Flow und erschüttert damit die Grundlage nachgelagerter Distributionen wie Rocky Linux und AlmaLinux
- Unter der GPL kann Quellcode zwar hinter einem kostenpflichtigen Abonnement liegen, doch Nutzungsbedingungen, nach denen bei Weiterverteilung das Abo gekündigt werden kann, können zu Problemen bei Rechtslage und Vertrauen der Community führen
- Entwickler sowie EPEL-/Fedora-Maintainer stehen vor der Belastung, ihre Testinfrastruktur neu auf den Red Hat Developer Account und 16 RHEL-Lizenzen auszurichten
- Geerling ist der Ansicht, dass Red Hat das in der Open-Source-Community aufgebaute Vertrauen aus Profitgründen verspielt; Rocky Linux und AlmaLinux erklärten, jeweils einen Weg zum Überleben finden zu wollen
Nach dem Ende von CentOS flammt das Problem des Zugangs zu RHEL-Quellen wieder auf
- Red Hat beendete vor zwei Jahren CentOS, eine weit verbreitete kostenlose Enterprise-Linux-Distribution
- Die CentOS-User-Community wurde als „freeloaders“ bezeichnet, die Red Hats Arbeit ohne Gegenleistung nutzen; Geerling sieht sich selbst als Teil dieser Community
- CentOS war die Grundlage, die Open-Source-Entwickler, Linux-Kernel-Beitragende und Softwareentwickler für Tests und Builds nutzten
- Geerling betont, dass auch Red Hat seine Produkte auf Linux aufbaut, das Red Hat weder geschaffen hat noch besitzt
Das Versprechen von 2020 und der Schaden für nachgelagerte Distributionen
- Es wird erwähnt, dass Red Hat nach den CentOS-Änderungen von 2020 versprochen hatte, die git-Quellen weiterhin öffentlich zugänglich zu machen
- Die aktuelle Änderung bringt auch Projekten wie SDL/PUIAS, einer RHEL-nachgelagerten Distribution, die länger als CentOS gepflegt wurde, große Schwierigkeiten
- Geerling sieht solche Distributionen in der aktuellen Lage als Kollateralschaden
Wie Rocky Linux und AlmaLinux eine massive Abwanderung verhinderten
- Dass Geerling nach dem Ende von CentOS im Red-Hat-Ökosystem blieb, hatte zwei Gründe
- Einige Red-Hat-Mitarbeiter suchten den Dialog und fragten „Wie können wir es besser machen?“, statt die Open-Source-User-Community anzugreifen
- Rocky Linux und AlmaLinux entstanden und wurden für Entwickler zu stabilen Zielen für Open-Source-Arbeit
- Allerdings waren beide Distributionen auf eine Struktur angewiesen, in der Red Hat Quellcode teilt
Bisheriger Ablauf der Veröffentlichung von RHEL-Quellen
- Der bisherige Ansatz ließ sich in folgender Reihenfolge verstehen
- Red Hat nimmt eine Kopie von Linux
- Red Hat fügt eigene Änderungen hinzu, damit daraus Red Hat Enterprise Linux wird
- Eine neue Version wird veröffentlicht
- Das Quellcode-Repository mit den Daten, die für einen Build von Grund auf nötig sind, wird aktualisiert
- In Open Source gilt: Quellen sind offen, und alle profitieren davon, dass man die Arbeit miteinander teilt
- Die von Linux verwendete GPL-Lizenz verlangt das Teilen von Quellen rechtlich
- Ohne dieses Teilen hätten zahlreiche Linux-Distributionen wie Debian, Arch, Mint, Ubuntu, PopOS und Fedora nur schwer existieren können
Quellen hinter einem kostenpflichtigen Abo und die Kontroverse um Nutzungsbedingungen
- Red Hat entschied, den Quellcode hinter eine Paywall zu stellen
- Geerling erkennt an, dass dieser Ansatz technisch gesehen unter der GPL möglich ist
- Er kritisiert ihn jedoch als respektlos und ärgerlich, weil ein großer Teil des gesperrten Codes auf Open-Source-Code anderer Menschen basiert
- Der größere Streitpunkt sind Red Hats aktuelle Abonnementbedingungen
- Red Hat sagt, dass das Unternehmen ein Konto kündigen kann, wenn ein Nutzer Quellcode herunterlädt und weiterverbreitet
- Wenn jemand mit einem Red-Hat-Abonnement die Quellen herunterlädt, eine neue Version von Rocky Linux baut und Red Hat dieses Abo dann kündigt, wäre das aus seiner Sicht ein Gerichtsverfahren, das man verfolgen sollte
- Ob die Community genug Geld aufbringen kann, um es mit IBMs mächtigen Anwälten aufzunehmen, ist ungewiss; Oracle wird jedoch als Akteur genannt, der dazu in der Lage sein könnte
- Red Hats Vorgehen bewegt sich nahe an der rechtlichen Grenze der GPL-Bedingungen von Linux; als Analyse dazu wird ein Beitrag der Software Freedom Conservancy angeführt
Die Einschätzung: Druck auf nachgelagerte Distributionen
- Aus Geerlings Sicht deuten die Umstände darauf hin, dass Red Hat nachgelagerte Distributionen wie Rocky, Alma und Oracle Linux unter Druck setzen will
- Er meint, Red Hat wolle die Nutzer dieser Distributionen verunsichern und zu Red-Hat-Abonnements bewegen
- Er fügt außerdem die zynische Deutung hinzu, dass diese Maßnahme nötig sei, um kurzfristige Gewinne zur Zufriedenheit von IBM abzusichern
Image als Open-Source-Unternehmen und der heutige Kontrast
- Red Hat war früher ein rebellisches Unternehmen, nutzte Werbung mit Gandhi-Zitat und positionierte sich als Underdog, der mit Open Source die etablierten proprietären Softwarefirmen aufmischt
- Heute ist Red Hat nahezu die Standardwahl, wenn Linux in großen Unternehmen betrieben wird
- Geerling findet, dass Cory Doctorows Formulierung zum Verfall von Plattformen, die er über andere Unternehmen schrieb, auch auf Red Hat passt
- Demnach behandeln Plattformen zuerst ihre Nutzer gut, beuten danach die Nutzer zugunsten von Geschäftskunden aus und beuten am Ende auch die Geschäftskunden aus, um selbst Wert abzuschöpfen, bevor sie sterben
- Für ihn wirft Red Hat beim Thema Linux den in der Open-Source-Community aufgebauten Goodwill aus Profitgründen weg
Praktische Belastung für Entwickler und Maintainer
- Entwickler wie Geerling, Maintainer des EPEL-Repositorys und Fedora-Maintainer sorgen sich um die langfristigen Auswirkungen
- Ihnen wird empfohlen, sich für einen Red Hat Developer Account zu registrieren und 16 RHEL-Lizenzen für Tests zu erhalten
- Geerling meint, dass man dadurch Testinfrastruktur und Automatisierung neu an Red-Hat-Lizenzen anpassen muss
- Debian, Ubuntu, FreeBSD und Rocky Linux verlangen solche Schritte nicht
- Er widerspricht auch Red-Hat-Mitarbeitern, die zur Nutzung von CentOS Stream raten
- Es gibt Gründe dafür, dass Rocky und Alma Linux millionenfach heruntergeladen wurden
- CentOS Stream ist aus seiner Sicht kein Ersatz für CentOS
Ende der Unterstützung für Enterprise Linux und Unbehagen wegen Ansible
- Geerling hat seit letztem Freitag in all seinen Arbeiten die offizielle Unterstützung für Enterprise Linux entfernt
- Er erhält auch Fragen zu Ansible
- Ansible beschreibt er als Red Hat Ansible Automation Platform, also als Produkt von IBM
- Er glaubt zwar nicht, dass Ansible versuchen wird, den Zugang zu beschränken, hält aber schon die Tatsache, dass man diese Möglichkeit auch nur kurz in Betracht ziehen muss, für abnormal
- Er will nichts auf einem Ökosystem aufbauen, in dem Open-Source-Nutzer als freeloaders bezeichnet werden und in dem mitten im Release-Zyklus zweimal hintereinander ohne jede Vorwarnung massive Verwerfungen passieren
Rocky und Alma kündigen an, einen Weg zu finden
- Geerling glaubt nicht, dass diese Angelegenheit Red Hat langfristig hilft
- Die Situation ist für alle drei Gruppen traurig
- Nutzer, die CentOS verwendeten und Tools entwickelten, die Menschen in das Red-Hat-Ökosystem brachten
- Red Hat, einst ein Unternehmen, das für Open Source kämpfte, jetzt aber Barrieren um den eigenen Quellcode errichtet
- Menschen, die im Red-Hat-Ökosystem bleiben und sich mit Lizenzproblemen sowie der Abwanderung der Open-Source-Community auseinandersetzen müssen
- Rocky Linux und AlmaLinux kündigten jeweils an, einen Weg nach vorn finden zu wollen
- Geerling sagt, dass er Rocky Linux und AlmaLinux nach bestem Bemühen weiter unterstützen werde, aber nicht sicher sei, ob er künftig Enterprise Linux unterstützen könne
1 Kommentare
Hacker-News-Kommentare
Ich halte solche emotionalen und in den Fakten etwas lockeren Stegreifkommentare nicht für besonders konstruktiv.
Ich bin mit dieser Entscheidung von Red Hat unzufrieden, und die Richtung, in die Red Hat geht, bereitet mir große Sorgen. Zum ersten Mal seit über zehn Jahren prüfe ich erneut, auf welches Ökosystem meine Arbeit und die Unternehmen, in denen ich Entscheidungen treffe, setzen sollen.
Es fällt mir schwer zu glauben, dass der Führung von Red Hat Open Source noch wirklich wichtig ist, und selbst wenn doch, hat sie meiner Ansicht nach gezeigt, dass sie Open Source schaden kann, um kurzfristig den Umsatz zu steigern.
Soweit ich weiß, wurde der Ausdruck freeloaders jedoch von einer einzelnen Person verwendet, und selbst im Kontext ist nicht klar, auf wen er sich genau bezog oder ob das eine persönliche oder eine Unternehmensmeinung war. Es wirkte auch nicht so, als seien damit Leute gemeint gewesen, die CentOS nutzten und tatsächlich zur Community beitrugen.
In großen Organisationen gibt es zwangsläufig Menschen mit Ansichten, denen nicht das ganze Unternehmen zustimmt; es ist unfair und unproduktiv, die gesamte Organisation anhand der Wortwahl einer einzelnen Person zu beurteilen.
Ich verstehe nicht, was hier das Ziel ist. Geht es darum, alles in Gut-und-Böse-Lager zu polarisieren, sodass am Ende alle nur noch das eigene Lager verteidigen, weil sie Angst haben, dass die „Gegenseite“ jedes Wort und jede Entscheidung gegen sie verwendet?
Ich mag den Content des OP sehr, aber ich mache mir etwas Sorgen, dass er zu tief in die YouTube-Erfolgsformel aus Emotionen eingestiegen ist, insbesondere ins Schüren von Wut und Ärger, und dieses Thema deshalb übertrieben emotional behandelt.
Nicht alle CentOS-Nutzer waren Trittbrettfahrer, und das gilt auch für die Nutzer der ideellen Nachfolge-Distributionen. Aber die meisten CentOS-Nutzer gaben weder an CentOS noch an die breitere Free-/Open-Source-Software-Community irgendetwas zurück.
Außerdem nutzten nicht wenige CentOS, weil sie alle Vorteile von Red Hat EL wollten, aber nicht dafür bezahlen wollten.
Das klingt ziemlich nach Trittbrettfahrerei. Copyleft-Open-Source-Lizenzen erlauben Trittbrettfahrerei, aber auch, dass Red Hat den Zugang zum Source Code einschränkt [1]. Solange gegenüber den Kunden die Lizenzpflichten erfüllt werden, ist das kein Problem.
Red Hat steckt enorme Summen in das Free-/Open-Source-Ökosystem, und ich finde es völlig fair, Kunden, die es sich problemlos leisten können, zum Bezahlen eines Abonnements zu bewegen. Für andere Nutzer gibt es viele Alternativen.
[1] Bei einer Nicht-Copyleft-Lizenz wäre Red Hat natürlich ohnehin nicht verpflichtet, den Source Code bereitzustellen.
„Nachdem es an der Zeit war, die meisten Klone loszuwerden, schaffte Red Hat sogar die offizielle Gratisversion seines kostenpflichtigen Kernprodukts ab. Stattdessen stellte das Unternehmen auf eine kostenlose Testversion um und kündigte das mit wohlklingenden Formulierungen wie Community-Beteiligung an. Tatsächlich wurden damit aus Sicht von Red Hat diejenigen abgeschnitten, die man als Horde von Trittbrettfahrern betrachten könnte. Zu diesem Schritt gehörte auch die kostenlose Produktionsnutzung von RHEL für Entwickler, allerdings nur bis zu 16 Maschinen.“
https://www.theregister.com/2023/06/23/red_hat_centos_move/
Beim zweiten Beitrag über Red Hat hatte ich ein ähnliches Gefühl. Manchmal postet er interessante Sachen, aber meistens ist das YouTube-artige Marketing zu aufdringlich.
Ich weiß, dass er das absichtlich macht, um Metriken zu bekommen, und ich hoffe, dass es für ihn gut funktioniert und das Publikum anzieht, das er haben will. Dass er es nicht ändert, deutet wohl darauf hin.
Ich erinnere mich an die erste Ankündigung, dass CentOS abgeschafft und durch CentOS Stream ersetzt werden sollte. Viele IBM- beziehungsweise Red-Hat-Mitarbeiter verteidigten die Änderung, indem sie CentOS-Nutzer so darstellten, als würden sie ein kostenpflichtiges Produkt kostenlos verwenden.
Auch auf Hacker News, Reddit und anderswo gab es viele, die es genau so verteidigten. Ich hoffe, wir versuchen jetzt nicht, die Geschichte umzuschreiben.
Sie sollten jedes Mal Angst vor Gegenwind haben.
Die Leute müssen tatsächlich bereit sein zu gehen. Sonst endet es wie bei Reddit, wo am Ende doch wieder alles beim Alten bleibt.
Ich kann Jeffs Standpunkt nachvollziehen, aber ich glaube, das ist jetzt schon sein dritter Beitrag zu diesem Thema auf der HN-Startseite innerhalb einer Woche.
Für mich gibt es aus diesem Stein inzwischen kein Blut mehr zu pressen. Jeff kann gern seinen Ball nehmen und nach Hause gehen, und ehrlich gesagt gilt das auch für Red Hat.
Aber ich glaube, das ist jetzt über die Phase „bemerkenswerte Nachricht“ hinaus, und die Diskussion kommt nicht weiter, wenn Jeff noch einen weiteren frustrierten Beitrag schreibt.
Ob es drei Beiträge gebraucht hat und ob alle auf die HN-Startseite mussten, weiß ich nicht, aber insgesamt scheint es mir auch kein so großes Problem zu sein. Die Leute haben eben entsprechend abgestimmt.
War ein Witz, aber vor ein paar Tagen musste selbst ich ihn erst googeln. Ich verfolge heutzutage nicht mehr viele Tech-YouTuber-Kanäle.
Um Jeffs Formulierung zu zitieren: Früher lief es so, dass Red Hat eine Linux-Kopie nahm, die „magische Soße“ hinzufügte, durch die daraus Red Hat Enterprise Linux wurde, eine neue Version veröffentlichte und dann alle zum Neubau von Grund auf nötigen Daten im Source-Code-Repository aktualisierte.
Zur Ergänzung: Dieser Teil mit der magischen Soße ist jetzt verschwunden. Geheime Quellen oder Blackbox-Geräte sind jetzt alle in CentOS Stream offengelegt.
Red Hat entwickelt RHEL nicht mehr hinter der Firmen-Firewall, sondern erledigt die gesamte Arbeit öffentlich in CentOS Stream. Es gibt eine Ausnahme bei Sicherheits-CVEs, aber praktisch landen diese mit dem Ende des Embargos gleichzeitig in CentOS Stream und RHEL.
Letztlich entsteht dieser Streitpunkt dadurch, dass CentOS Stream absichtlich ignoriert wird. RHEL-Klone müssen einfach nur CentOS Stream folgen, und auch die „geheime Soße“ des CI/CD-Ablaufs von CentOS Stream lässt sich nachbilden.
Der Prozess, RHEL nachzubauen, ist heute deutlich einfacher als jemals zuvor.
Vor ein paar Wochen war es einfacher, eine Replik zu erstellen, die bis hin zu den Bugs identisch ist. Jetzt ist dafür mehr Aufwand nötig. Außerdem macht man diese Arbeit parallel zu Red Hat selbst, was zu doppeltem Aufwand führt.
Wenn man dann noch bedenkt, dass Rocky und AlmaLinux zu dieser Änderung mitten im 9.x-Release-Zyklus gezwungen wurden und dass auch das frühere Ende von CentOS mitten im 8.x-Release-Zyklus mit weniger als 24 Stunden Vorwarnung kam, fällt es schwer zu glauben, dass diese Änderung „nur dazu dient, die Entwicklung von CentOS und RHEL zu verbessern“.
Wenn das wirklich das Ziel gewesen wäre, hätte man es wenigstens ein paar Wochen, besser noch ein paar Monate vorher ankündigen müssen, damit die Community planen kann. Stattdessen wurden wir zweimal hintereinander überrumpelt.
Allerdings verkürzt die Formulierung, man nehme einfach „eine Linux-Kopie“, die enorme Menge an Arbeit, die Red Hat in die Erstellung eines RHEL-Releases steckt, auf fast groteske Weise.
Red Hat bündelt Hunderte oder Tausende Upstreams zu RHEL, beteiligt sich an vielen davon, testet das Gesamtsystem gemeinsam und hilft Partnern dabei, Software dafür zu zertifizieren, neben vielen anderen Dingen.
Es stimmt, dass Red Hat den Linux-Kernel nicht „besitzt“, aber das Unternehmen hat über lange Zeit massiv zur Kernel-Entwicklung beigetragen. Und RHEL ist nicht nur der Kernel und auch nicht nur ein einzelner Upstream. Es ist das Ergebnis davon, Tausende Pakete gemeinsam zu testen und als unterstütztes Produkt auszuliefern.
Was Red Hat schützen will, ist nicht der Source Code eines einzelnen Projekts oder mehrerer Projekte, sondern der Wert, der dadurch entsteht, all diese Teile zusammenzubringen. Und zufälligerweise ist genau dieser Wert auch das, was Unternehmen, Wettbewerber und die Community wollen, nicht der Source Code an sich.
Alle wollen im Grunde einen Snapshot zu einem bestimmten Zeitpunkt, auf den man sich faktisch als Standard geeinigt hat. Denn die gesamte Community konnte sich nicht auf einen anderen tragfähigen Standard einigen, den Anwendungen breit als Zielplattform nutzen könnten. Dieser Standard hat einen Namen: RHEL, und er gehört Red Hat.
Wenn man will, kann man alle Einzelteile nehmen und selbst zusammensetzen. Aber niemand außer Red Hat hat das Recht, das Ergebnis offiziell oder inoffiziell als RHEL zu zertifizieren.
Wenn dich das wütend macht, kann ich nur ernsthaft empfehlen, Debian zu einem Standard auszubauen, auf den alle bei Zertifizierungen abzielen. Oder gründe ein Unternehmen, das Red Hat übertrifft und den Platz einnimmt, den RHEL heute innehat.
Mark Shuttleworth hat jahrelang das RHEL-Geschäftsmodell von Red Hat kritisiert, aber wenn man sich Ubuntu Pro ansieht, wo Paket-Updates nach fünf Jahren ausgelagert werden und Geld für Updates in den Repositories Universe und Main verlangt wird, wirkt das ziemlich ähnlich.
Oracle Linux, Alma Linux und Rocky Linux sind alle Downstreams von RHEL.
Man kann den ganzen Tag lang behaupten, CentOS Stream sei RHEL sehr ähnlich. Man kann auch sagen, dass es für einen selbst keine große Sache ist, dass es jetzt der Upstream ist.
Aber in der Praxis ist es für viele Nutzer und Unternehmen wichtig, ob etwas Upstream oder Downstream ist.
Es ist auch wichtig, dass IBM versucht, den Zugang zu Open-Source-Code einzuschränken und Abonnenten daran zu hindern, denselben Open-Source-Code weiterzuverteilen.
IBM richtet enormen Schaden im Open-Source-Ökosystem an, von dem das Unternehmen selbst profitiert.
Ich bin die Person, die diesen Tweet geschrieben hat.
Mike, der das zuerst auf Mastodon angesprochen hatte, hat gerade seinen Tweet, oder vielmehr toot, aktualisiert und geschrieben, dass sein Kontakt bei Red Hat bestätigt habe, dass dies ein Bug sei.
Das Entwickler-Abonnement ist weiterhin auf 16 Server begrenzt.
https://twitter.com/fareszr/status/1673145072714665984
RHEL hat einen großen Vorteil im Treiber-Ökosystem, dessen Tragweite ihnen womöglich selbst nicht ganz bewusst ist. Ich denke, dass man riskiert, das kaputtzumachen
Als die Branche begann, Linux ernst zu nehmen, war RHEL die dominierende Distribution. Dadurch wurden RHEL und seine abgeleiteten Distributionen eher zufällig zum Hauptziel kommerzieller Hardware-Treiber
Zum Beispiel lassen sich wenig bekannte Low-Latency-Netzwerkkarten oder Packet-Capture-Karten auf RHEL-Ablegern oft leichter zum Laufen bringen als auf anderen Systemen. Wenn man mit den Firmen spricht, die solche Geräte herstellen, setzen sie die RHEL-Familie als De-facto-Standard voraus
Dank der Treiberunterstützung wurden Red-Hat-Ableger zum Standard unter kommerziellen Distributionen. Red Hat selbst hat sich dieses Ausmaß bei den Deployments aber nicht gesichert. Die tatsächliche Verbreitung liegt bei CentOS/Rocky/Alma in Hedgefonds, Proprietary-Trading-Firmen, Öl-Explorations-Grids usw.
Meiner Ansicht nach ist genau diese Treibersituation der eigentliche Wert des Red-Hat-Ökosystems. Der User-Space ist eher chaotisch und der Paketmanager auch nicht besonders beeindruckend. Trotzdem setzt man RHEL-Ableger ein, weil die Treiber ohne große Probleme funktionieren
Falls Red Hat abgeleitete Distributionen beseitigen könnte, würde das einen Wendepunkt auslösen, an dem die Branche die RHEL-Familie nicht länger als Standardziel für Treiber behandeln würde
Ein Unternehmen, das 5.000 Server mit CentOS betreibt, wird nicht plötzlich 350 Dollar pro Server und Jahr zahlen. Es wird zu Debian wechseln und die Schmerzen der Umstellung in Kauf nehmen. Die Kultur rund um kommerzielle Treiber würde schnell folgen. So ein kultureller Wandel würde nicht Jahre dauern, sondern Tage
Das Abrechnungsmodell von Red Hat pro Server halte ich für naiv. Für 350 Dollar im Jahr bekommt man nur eine Lizenz ohne Support. Bei kleinen Unternehmen und Firmen mit traditionellen Service-Erwartungen mag das etwas Umsatz bringen, aber liegt dort wirklich die Chance
Wenn man ein Rechenzentrum aufbaut, möchte man jeden Server per PXE booten. So kann man System-Images für ein Grid ändern, indem man ein neues PXE-Image baut und die Hosts neu startet. Diese Konfiguration aufzusetzen ist mühsam, und es wäre gut, wenn Red Hat dafür eine gut gemachte Standardlösung anbieten würde
Ein Modell wie 2.000 Dollar pro Jahr für 100 Server pro Standort, inklusive echtem Support für die PXE-Appliance, würde reichen. Wenn Red Hat diesen Weg einschlägt, könnte es mit abgeleiteten Distributionen koexistieren. Als Appliance umgesetzt könnte das zu einem allgegenwärtigen Produkt wie Firewalls oder Netzwerk-Switches werden
Ich dachte, RHEL setzt im Grunde Patches auf denselben Kernel, ohne die Interfaces stark zu verändern. Deshalb würde ich erwarten, dass Treiber im Quellformat oder auch manche Treiber als Binary Blobs auf einem allgemeinen Kernel nahezu genauso gebaut werden und laufen sollten
Außer dem Punkt, dass Treiberentwickler eben RHEL/CentOS verwenden und die Funktion dort verifiziert haben: Übersehe ich etwas
Die vom OP verlinkte juristische Analyse zu RHEL und der GPL von der Software Freedom Conservancy war am interessantesten
https://sfconservancy.org/blog/2023/jun/23/rhel-gpl-analysis...
Man kann den GPL-Code anderer in einem Produkt verwenden und dafür Geld nehmen. Auf Anfrage muss man den GPL-Quellcode und den eigenen aus GPL-Code abgeleiteten Quellcode „offenlegen“. Offenlegen heißt hier, dass man ihn auf Verlangen herausgeben muss; es heißt nicht, dass man eine öffentliche Download-Seite haben oder ihn leicht zugänglich machen muss
Man kann ihn auf dem gewünschten Medium verschicken, etwa auf DVD oder Flash-Laufwerk, und ungefähr die Kosten des Mediums berechnen. Man muss es also nicht leicht machen, an den Source Code zu kommen, und man muss das gebaute Produkt auch nicht kostenlos bereitstellen
Innerhalb der Grenzen der GPL ist vieles möglich. Wenn IBM/Red Hat sich innerhalb dieser Grenzen bewegt, was genau ist dann das Problem
So etwas ist auch ohne GPL möglich. SQLite3 ist zum Beispiel Public Domain, aber es gibt das SQLite Consortium, das D. R. Hipp und seinen Mitarbeitern vermutlich ziemlich gute Einnahmen verschafft. Der Grund, warum es fast keine Konkurrenz durch Forks gibt, ist, dass SQLite3 sehr schwer verlässlich zu forken ist, weil die bessere Test-Suite proprietär und geheim ist
Für Unternehmen ist Open Source ein Werkzeug. Für Einzelpersonen ebenfalls. Wenn ein junger Mensch am Anfang steht und nur wenige Ressourcen hat, kann es sinnvoll sein, nützliche Software als Open Source zu veröffentlichen, um sich einen Ruf aufzubauen und bessere Chancen auf Anstellung oder zur Gründung eines eigenen Unternehmens zu bekommen
Die MBAs von IBM haben Red Hat jetzt endlich vollständig übernommen
Es ist diese Haltung, noch einen weiteren Dollar herauszupressen, selbst wenn es sich langfristig rächt. Dass es irgendwann passieren würde, war klar, und ehrlich gesagt überrascht mich eher, dass es so lange gedauert hat
So etwas sieht man heute in vielen Unternehmen. Projekte werden gestartet, die nirgendwohin führen oder bald wieder eingestellt werden, die Boni werden ausgezahlt, die Leute ziehen weiter, und dann wiederholt sich alles
Der Dumme ist nur, wer für langfristige Gewinne bleibt. Anders betrachtet haben Arbeitnehmer vielleicht endlich das Geheimnis der Unternehmen durchschaut
Diese Entscheidung scheint unter starker Beteiligung vieler langjähriger Mitarbeiter getroffen worden zu sein. Was, wenn in Wirklichkeit genau das Gegenteil zutrifft
Die Formulierung, man solle auch noch ignorieren, dass Red Hat sein Produkt auf Linux aufbaut, das sie weder geschaffen noch besitzen, scheint zu übersehen, dass ein großer Teil des anhaltenden Erfolgs von Linux Red Hat zu verdanken ist
Red Hats Einfluss war groß: Es hat Compliance vorangetrieben und die dazu passende Entwicklung finanziert, sodass Linux bei Regierungsaufträgen konkurrenzfähig werden konnte, und auch die von Red Hat direkt unterstützte Linux-Entwicklung ist enorm
Natürlich ist Red Hat nicht allein der Grund für den Erfolg von Linux, aber der Erfolg von RHEL hat eindeutig eine große Rolle dabei gespielt, Linux für Rechenzentren tauglich zu machen
Linux wurde durch graswurzelartige Verbreitung populär, und erst danach haben Unternehmen begonnen, daran Geld zu verdienen. Heute gibt es ein Narrativ, nach dem Unternehmen das Spiel von Anfang an in Gang gesetzt hätten, aber das stimmt nicht
Es gibt einige Gründe, warum Stream kein Ersatz für die CentOS-Familie, also Alma, Rocky usw., sein kann
Erstens kann Stream nicht als Grundlage zum Bauen EL-kompatibler Pakete verwendet werden. Es gibt keine Garantie, dass Stream die ABI-Kompatibilität nicht bricht
Zweitens hat Stream keinen langen, über mehrere Jahre laufenden Support-Zyklus und kann daher nicht als stabiles System genutzt werden. Natürlich braucht man den kostenpflichtigen Lizenz-Support von Red Hat nicht, und es gibt eine große Community, die bereit ist, mit Bug-Reports und Tests zu helfen
Streng genommen kann man sagen, dass es keine Garantie gibt, aber ein solcher Bruch wäre ein Bug, weil er auch künftige RHEL-Releases kaputtmachen würde
Die Support-Dauer beträgt 5 Jahre
Ich unterstütze zu 100 % und bin dankbar dafür, dass jeder, einschließlich Jeff, das Recht hat, eine Haltung einzunehmen, wenn er entscheidet, wofür er seine Zeit einsetzt
Unsere Zeit ist begrenzt, und besonders wenn sich das ändert, was einem wichtig ist, muss man diese Zeit entsprechend einsetzen. Jeffs Beitrag „Saying No“ vermittelt sehr gut, warum das wichtig ist
Schwer nachvollziehbar finde ich allerdings, dass viel zu viele IBM-Anekdoten verwendet werden, Formulierungen so umgebaut werden, dass es wirkt, als hätte Red Hat sich respektlos gegenüber der Community geäußert, und die Dreistigkeit, die nötig ist, um Dinge zu sagen wie „Sagt den Mitarbeitern, sie sollen [eine bestimmte Handlung] einstellen“
Ich verstehe, dass sich diese Sache wie ein Vertrauensbruch angefühlt haben kann und dass gebrochenes Vertrauen vermutlich am meisten schmerzt. Deshalb verstehe ich auch die emotionale Reaktion
Aber um als Open-Source-Maintainer oder Contributor die eigene kognitive Belastung deutlich zu verringern, wäre es wohl besser gewesen, den Support einfach einzustellen und weiterzugehen
https://www.jeffgeerling.com/blog/2022/just-say-no