- Die Änderung der Bedingungen für die Bereitstellung des RHEL-Quellcodes von Red Hat muss im langen historischen Kontext von Unix, GNU, Linux und IBM betrachtet werden; IBM/Red Hat vertreten die Position, dass sie das GPL-Prinzip „Quellcodebereitstellung an Empfänger von Binärdateien“ einhalten
- Frühe Software wurde von Forschern und Nutzern je nach Bedarf erstellt und geteilt, doch seit den 1980er-Jahren wurden Urheberrecht und Lizenzen stärker durchgesetzt, wodurch sich EULA, Quellcodeverträge, permissive Lizenzen und die GPL auseinanderentwickelten
- GNU und Linux wuchsen durch offenen Quellcode und Beiträge der Community, und IBM stärkte das Vertrauen ins Ökosystem, nachdem das Unternehmen eine Investition von 1 Milliarde US-Dollar in Linux angekündigt sowie Entwickler eingestellt und auf die SCO-Klagen reagiert hatte
- RHEL ist ein Enterprise-Server-Produkt, das Fedora als experimentelle Basis nutzt, und Red Hat versucht, die Kosten für Support, QA, Dokumentation, Release Engineering und globale Supportstrukturen über Kundenlizenzen hereinzuholen
- Nutzer von RHEL-Klonen können andere Linux-Distributionen wählen, doch für Klonhersteller wäre es produktiver, statt einfacher Kopien eine mit RHEL konkurrierende Distribution zu bauen
Grundhaltung zur Red-Hat-Änderung
- Die jüngste Änderung der Verkaufsbedingungen von Red Hat hat Kontroversen ausgelöst, doch im Kern geht es darum, wie Kunden, die RHEL-Binärdateien erhalten haben, den Quellcode bekommen
- Das Wesen der GPL besteht darin, Quellcode und Änderbarkeit zu garantieren, damit Empfänger von Binärdateien Bugs beheben und das Betriebssystem erweitern können
- IBM/Red Hat sehen ihre Pflicht als erfüllt, indem sie Vertragskunden den Quellcode und die für die Build-Erstellung der Distribution nötigen Informationen bereitstellen und Änderungen an GPL-Code weiterhin upstream senden
- Der Begriff „Community“ allein reicht schwer aus, um alle Interessen zusammenzufassen, und Nutzer, die nicht dasselbe Maß an Engineering und Support benötigen, können andere Linux-Distributionen wählen
Vom Teilen von Software zum Zeitalter der Lizenzen
- Um 1969 wurde Programmierung vor allem von Forschern, Professoren und Ingenieuren für die eigene Arbeit betrieben, und der Beruf des „professionellen Programmierers“ war noch nicht verbreitet
- Nutzergruppen wie DECUS verteilten von Kunden geschriebene Software zu reinen Kopierkosten, und viele Nutzer veröffentlichten ihren Code als Public Domain
- Damals war die Anwendbarkeit von Urheberrecht oder Patenten auf Software begrenzt, daher musste man sich zum Schutz von Code auf Geschäftsgeheimnisse, Vertragsrecht und die Verteilung von Binärdateien stützen
- Anfang der 1980er-Jahre wurden starke urheberrechtliche Grundsätze auf Binärdateien und Quellcode angewendet, sodass Entwickler Lizenzen brauchten, um den Nutzern ihre Rechte zu erläutern
- Für Endnutzer entstanden EULAs
- Für Entwickler galten separate Quellcodeverträge
Das Fundament aus Unix, BSD und GNU
- Unix begann 1969 in den Bell Labs und verbreitete sich später an Forschungsuniversitäten wie UC Berkeley, MIT, Stanford und CMU
- BSD Unix von UC Berkeley bot demand-paged virtual memory, natives TCP/IP und umfangreiche Utilities und wurde zur Grundlage mehrerer früher Unix-Anbieter
- Produkte wie SunOS, Ultrix und HP/UX nutzten BSD als Basis
- John Lions’ Kommentar zu Unix Version 6 konnte lange nicht offiziell veröffentlicht werden, doch über Kopien brachte er zahllosen Unix-Programmierern den Aufbau des Kernels und das dahinterliegende Designdenken bei
- Die Unix-Quellcode-Lizenzen von AT&T waren teuer und restriktiv, daher entschieden sich einige Unternehmen für Redistributor-Verträge, um Unix-ähnliche Systeme nur als Binärdateien zu verkaufen
- Richard M. Stallman startete das GNU-Projekt, nachdem er mit Unix-Distributionen konfrontiert war, die nur Binärdateien lieferten, und das Problem sah, dass Nutzer notwendige Änderungen nicht selbst vornehmen konnten
- Das Ziel von GNU war ein freies Betriebssystem, bei dem diejenigen, die Binärdateien verteilen, den Empfängern Quellcode und Änderbarkeit garantieren
- Zuerst wurde Software geschaffen, die für Programmierer direkt nützlich war, etwa emacs, Compiler-Suites und Utilities
Der Unterschied zwischen permissiven Lizenzen und der GPL
- Universitäten wie MIT und UC Berkeley wollten Forschungscode eher verbreiten als verkaufen, benötigten nach der Durchsetzung des Urheberrechts aber Lizenzen mit Nutzungsbedingungen und Haftungsausschlüssen
- Diese Lizenzen wurden später als permissive Lizenzen im Open-Source-Bereich bezeichnet
- Entwickler können Distributionen erstellen, die nur Binärdateien enthalten
- Änderungen, die über den ursprünglich erhaltenen Quellcode hinausgehen, müssen Endnutzern nicht offengelegt werden
- Die GPL wurde als restriktive Lizenz eingeordnet, die erzwingt, dass Endnutzer, die Binärdateien erhalten, auch die Änderungen sehen können
- Zur GPL gab es anfangs verschiedene Missverständnisse
- Manche glaubten, auch mit GNU-Compilern erzeugte Binärdateien unterlägen automatisch der GPL
- Andere meinten, GPL-Code dürfe nicht verkauft werden, was RMS zurückwies
- Unternehmen wie Walnut Creek und Prime Time Freeware for Unix verkauften Sammlungen verschiedener Open-Source-Programme auf CD-ROM und DVD
Druck auf den Unix-Markt und der Aufstieg von Linux
- Systemanbieter wie DEC, HP, Sun und IBM entwickelten Unix-ähnliche Betriebssysteme auf Basis von AT&T System V oder BSD und beschäftigten dafür Ingenieure, technische Redakteure, QA-Mitarbeiter und Produktmanager
- Um ein wettbewerbsfähiges Unix-ähnliches System zu bauen, fielen pro Unternehmen nach dieser Sicht jährlich Kosten von rund 1 bis 2 Milliarden US-Dollar an
- Microsoft verkaufte dasselbe Betriebssystem unabhängig vom PC-Hersteller und setzte die Unix-Anbieter unter Druck, als das Unternehmen in den Markt für Server-Betriebssysteme vordrang
- Das Linux-Kernel-Projekt entstand Ende 1991 aus dem Zusammenwirken mehrerer Faktoren und war Ende 1993 in einer Phase, in der mehrere Distributionen zu wachsen begannen
- Software aus GNU, MIT, BSD und unabhängigen Projekten existierte bereits
- Im Internet gab es immer mehr Informationen über das Innenleben von Betriebssystemen
- Schnelles Internet begann Privathaushalte zu erreichen
- Günstige Prozessoren mit demand-paged virtual memory wurden verbreitet
- Glück und Gelegenheit spielten eine Rolle
- Es gab einen sturen und charismatischen Projektleiter
- Distributionen wie Soft Landing Systems, Yggdrasil, Debian, Slackware und Red Hat tauchten auf; einige starteten als kommerzielle Distributionen, andere als Community-Projekte
Linux und das Community-Modell
- Einer der Gründe, warum Linux vor BSD öffentliche Aufmerksamkeit erhielt, war, dass BSD in die Klage „Unix Systems Labs Vs BSDi“ verstrickt war
- Die GPL entfaltete einen dynamischen Effekt, indem sie die Verteilung des Quellcodes zusammen mit den Binärdateien erzwang; so konnte jeder ohne Erlaubnis ein Distributionsprojekt starten, wodurch Hunderte von Distributionen entstanden
- Das X Window System stammt aus dem MIT Project Athena, ebenso Kerberos
- Die Entwicklung des X Window System wurde von MIT und Project Athena an das X Consortium übergeben; das X Consortium wurde 1993 eröffnet und 1996 geschlossen
- Die OSF wurde gegründet, um Quellcode- und API-Standards für Unix-Systeme zu etablieren, und fusionierte 1996 mit X/Open zur Open Group
- Mehrere Konsortien folgten anfangs dem Muster reichlicher Finanzierung, verloren dann aber Geld, weil beteiligte Unternehmen ausstiegen in der Annahme, „ein anderes Unternehmen werde die Kosten schon tragen“
Das Nachhaltigkeitsproblem der FOSS-Entwicklung
- In der frühen FOSS-Welt arbeiteten wenige Entwickler mit großer Leidenschaft für wenige Nutzer, oft ohne Bezahlung
- Als die Zahl der Nutzer schneller wuchs als die der Entwickler, nahm der Wartungsdruck zu
- Besonders deutlich zeigte sich der Mangel an Entwicklern in „nicht sexy“ wirkenden Bereichen wie QA, Release Engineering, Dokumentation und Übersetzung
- Einige Entwickler fühlten sich unwohl dabei, dass andere mit Code Geld verdienten, den sie kostenlos beigesteuert hatten, doch hier wird die Position vertreten, dass Unternehmen mit Linux Geld verdienen können müssen, damit Linux schnell vorankommt
- Mit der Zeit umfasste die Community nicht mehr nur Code-Autoren, sondern auch Menschen für Dokumentation, Übersetzung und Öffentlichkeitsarbeit; später nahm auch die Zahl derjenigen zu, die nur gratis Software nutzten und freedom software nicht verstanden
Softwarepiraterie und die Kosten freier Software
- Softwarepiraterie bedeutet das illegale Kopieren und Nutzen von Software entgegen den Lizenzbedingungen
- Einige Mitglieder der FOSS-Community nehmen geistiges Eigentum oder Urheberrecht auf die leichte Schulter, doch ohne Urheberrecht ginge auch die Kontrolle über Software verloren
- Auf einer Konferenz in Brazil sagte der Autor, man solle „Free Software nutzen“, worauf das Publikum antwortete: „Unsere Software ist ohnehin alle free“
- Damals waren fast 90 % der Desktop-Software in Brazil Raubkopien
- Unter solchen Bedingungen geht ein Teil des Kostenvorteils von Free Software verloren
- Nach dieser Sicht ließe sich der Großteil der FOSS-Entwicklung leicht finanzieren, wenn jeder Nutzer des Linux-Kernels pro Hardwareplattform nur 1 Dollar zahlen würde
IBMs Einstieg bei Linux
- Innerhalb von IBM gab es Menschen, die an FOSS glaubten und in ihrer Freizeit an Projekten arbeiteten; Daniel Frye wollte sie in einer internen FOSS-Organisation bündeln, um Linux voranzubringen
- In Erinnerung ist ein Schreiben von IBMs Lou Gerstner mit der Aussage, dass IBM früher nur dann Open Source nutzte, wenn es geschäftliche Gründe gab, künftig aber nur dann Closed Source wählen werde, wenn es geschäftliche Gründe dafür gebe
- IBM kündigte damals eine Investition von 1 Milliarde US-Dollar in Linux an, was große Aufmerksamkeit auslöste
- Danach stellte IBM Linux-Entwickler ein, damit sie in verschiedenen Linux-Bereichen in Vollzeit arbeiten konnten, und bezahlte Entwickler auch in Bereichen wie dem Apache Web Server
- Etwa ein Jahr später hatte IBM die erste Milliarde wieder eingespielt und kündigte an, noch eine weitere Milliarde zu investieren
- IBM verkaufte das Notebook- und Desktop-Geschäft an Lenovo und übernahm Price Waterhouse Cooper, womit sich das Unternehmen in Richtung Business-Solutions-Unternehmen bewegte
- Business Solutions mussten danach nicht mehr nur an IBM-Hardware und -Software gebunden sein
- Open Source wurde als Faktor gesehen, mit dem IBM-Lösungsanbieter bessere Lösungen zu geringeren Kosten erstellen konnten
IBMs Rolle in den SCO-Klagen
- Santa Cruz Operations entwickelte eine Unix-Distribution auf Basis von AT&T-Code und wurde später an die Caldera Group verkauft
- Nach der Umbenennung in SCO verfolgte Caldera eine Klagestrategie gegen Linux-Anbieter mit der Behauptung, Linux enthalte AT&T-Quellcode und verletze Lizenzbedingungen
- Ein großer Teil der Linux-Community hielt diese Behauptung für falsch, und aus Erfahrung mit den Verträgen zwischen AT&T und Novell erschien auch die Behauptung unglaubwürdig, Santa Cruz Operations besitze das Urheberrecht am AT&T-Code
- IBM, Novell, Red Hat und andere beteiligten sich an den Rechtsstreitigkeiten, und am Ende kam das Gericht nach dieser Darstellung zu dem Ergebnis, dass SCO nur Fragen zu einem erloschenen Vertrag mit IBM aufwerfen könne, Linux selbst aber unproblematisch sei
- Dass Big Blue in den Rechtskampf einstieg, gab Linux-Anbietern und -Nutzern das Vertrauen, dass die Sache gut ausgehen würde
Das Geschäftsmodell von Red Hat und RHEL
- Red Hat begann als kleines Unternehmen in Raleigh mit starker technischer Kompetenz, aber schwachen Fähigkeiten in Business und Marketing; Bob Young stieß dazu und half dabei, Unternehmenspolitik und Ausrichtung zu formen
- Bob Young verglich Red Hat damit, „das Heinz Ketchup von Linux“ zu werden, und Red Hat verdiente Geld mit einem servicebasierten Modell
- Mit der Zeit konzentrierte sich Red Hat auf ein Enterprise-Geschäft rund um RHEL
- Der Desktop war nur als Entwicklungsplattform für RHEL wichtig, und die Desktop-Entwicklung wurde Fedora überlassen
- Fedora dient als Testbasis für neue Ideen, die später in RHEL einfließen sollen
- RHEL-Kunden sind Unternehmen und Behörden, die „mission critical“ und „always on“ verlangen und oft nicht Dutzende oder Hunderte, sondern Tausende Systeme betreiben
- Solche Kunden verhandeln über MTTF, MTTR und 99,999 % Verfügbarkeit sowie Strafklauseln und erwarten nicht nur normalen First-Level-Support, sondern Support auf zweiter und dritter Ebene
- Red Hat investiert in Enterprise-Support, QA, Dokumentation, Zertifizierung und Release Engineering, und die Kunden bezahlen dafür
Full-Stack-Unternehmen und die Logik hinter IBMs Übernahme von Red Hat
- Der Fall, dass Oracle das geistige Eigentum von Sun Microsystems übernahm, wird als Full-Stack-Strategie beschrieben, bei der Hardware, Betriebssystem und Anwendungen gemeinsam kontrolliert werden
- Ein Full-Stack-Unternehmen kann den gesamten Stack verändern, um Anwendungen Vorteile zu verschaffen, und den kompletten Stack testen, um Ineffizienzen und Schwächen zu finden
- IBM und Apple werden als Full-Stack-Unternehmen eingeordnet; ihre Produkte sind teurer, doch viele ernsthafte Kunden zahlen diesen Preis
- IBM brauchte für sein Business-Solutions-Geschäft Linux-basierte Full-Stack-Lösungen, und Red Hats RHEL verfügte über den Ruf und das Engineering für Enterprise-Lösungen
RHEL-Klone und die Änderung der Red-Hat-Bedingungen
- Mit der Zeit entstand bei einigen Kunden das Muster, nur eine kleine Zahl von RHEL-Systemen zu kaufen und auf den übrigen Systemen andere Distributionen einzusetzen, die mit Red Hat bug-for-bug kompatibel waren
- Diese Vorgehensweise senkte die Kosten der Kunden, verringerte aber auch die Einnahmen von Red Hat trotz gleichbleibender Arbeit; dadurch geriet Red Hat unter Druck, entweder die Lizenzpreise zu erhöhen, Personal abzubauen oder andere Projekte aufzugeben
- IBM/Red Hat trafen daher die geschäftliche Entscheidung, Quellcode und Build-Informationen nur noch an Kunden zu verteilen, die für alle laufenden RHEL-Systeme Lizenzen erwerben
- Diese Bedingung wird als vereinbar mit dem Kern der GPL betrachtet
- Wer Binärdateien erhält, kann den Quellcode bekommen, Bugs beheben und Erweiterungen vornehmen
- Red Hat und IBM schicken Änderungen an GPL-Code weiterhin upstream
- Auch der Austausch mit der größeren Community und von Ideen wird fortgesetzt
- Klonentwickler werden hier nicht als „freeloader“ bezeichnet, doch Nutzer, die Klone verwenden und der Community in keiner Form etwas zurückgeben, bewegen sich demnach nahe am freeloading
Der Vorschlag: Wettbewerb statt Klone
- Nach der Red-Hat-Änderung erklärten mehrere Distributionen, weiter „not RHEL“ bauen zu wollen, was für normale Nutzer eher noch verwirrender machen könne, welche Distribution sie wählen sollen
- Statt mehrere getrennte Klone zu entwickeln, sei es besser, gemeinsam eine gute Distribution zu bauen oder einen echten Wettbewerber zu RHEL zu schaffen
- Positiv bewertet wird, dass SuSE 10 Millionen US-Dollar investieren wolle, um einen RHEL-Konkurrenten zu schaffen
- Allerdings sind dieselben Geschäftskanäle, weltweiten Support-Teams und Enterprise-Supportstrukturen nicht billig aufzubauen
- 10 Millionen US-Dollar könnten ein Anfang sein
- RHEL-Kunden sollten sich wegen des Werts des Supports entscheiden, den Red Hat/IBM und ihre Channel-Partner bieten
- Wenn IBM nicht länger mit Kunden Geschäfte machen will, die nur eine RHEL-Kopie kaufen und den Rest mit freien Distributionen betreiben möchten, dann müssen diese Kunden einen anderen Enterprise-Linux-Anbieter finden, der mit diesem Kundentyp umgehen kann
Persönliches Fazit
- Jon „maddog“ Hall sagt von sich, dass er schon vor Open Source, der Free Software Foundation und dem GNU-Projekt Quellcode offengelegt und Kunden Quellcode bereitgestellt habe
- Beiträge zur Community beschränken sich nicht auf das Schreiben von Code, Dokumentation oder Bug-Reports
- Man kann Free Software an Schulen, in Unternehmen und in Behörden bekannt machen
- Man kann Linux Clubs gründen oder Aktivitäten wie Upgrade to Linux unterstützen
- Unternehmen können Geschäftsbedingungen festlegen, solange sie keine Lizenzen verletzen, und Kunden können diese annehmen oder ablehnen
- Es ist unausgewogen, Red Hat und IBM als „böse“ darzustellen, zugleich aber Unternehmen nicht in gleicher Weise zu betrachten, die auf permissiven Lizenzen basieren, Endnutzern keinen Quellcode garantieren oder nur Closed-Source-Lizenzen anbieten und keine Klone zulassen
- Für Forscher, Studierende, Hobbyanwender und Menschen mit kaum Geld gibt es Hunderte Linux-Distributionen, darunter auch solche mit Unterstützung für Architekturen, die RHEL nicht abdeckt
1 Kommentare
Hacker-News-Kommentare
Seit Ende der 90er habe ich Red Hat Linux (anfangs Caldera Linux, ein 90er-Klon), Fedora, RHEL und dessen Klone (Scientific, CentOS, Rocky) privat, in der Lehre und beruflich genutzt und sie auch für Desktops und Server empfohlen.
Wenn jemand Linux nutzen wollte, sagte ich oft, die beiden stabilen und gut unterstützten Optionen seien Red Hat und Debian; Red Hat halte ich inzwischen für tot. RIP
Ich bin mir nicht mehr sicher, ob Fedora weiterhin ein aktives Open-Source-Projekt bleiben wird. Wenn IBM gerade die RHEL-Klone abwürgt, warum sollte man das Risiko eingehen und glauben, dass Fedora nicht als Nächstes dran ist?
Ich weiß, dass es heißt „RHEL leitet sich von Fedora ab“ und „Fedora ist ein eigenständiges Open-Source-Projekt“, aber inzwischen leitet sich RHEL von CentOS Stream ab. Dann frage ich mich, wozu Fedora noch nötig ist und warum Red Hat Engineering und Infrastruktur für Fedora bereitstellen sollte.
Fedora ist zwar ein eigenes Projekt, aber der Großteil der Beiträge kommt von Red-Hat-Mitarbeitern. Wenn IBM morgen entscheidet, dass CentOS Stream ausreicht, und die Finanzierung von Fedora einstellt, kann Fedora dann unabhängig überleben?
Das mag bloße Angst, Unsicherheit und Zweifel (FUD) sein, aber ich vertraue keiner Linux-Distribution im Besitz von IBM mehr. Meine privaten Geräte habe ich bereits auf Debian umgestellt, und auch beruflich empfehle ich Debian. Für eine Organisation, die ihre Linux-Installationen stark anpasst, halte ich es für unverantwortlich, statt eines uneingeschränkt vollständig offenen Open-Source-Projekts eine unsichere, auf Red Hat/IBM basierende Distribution zu wählen. Einmal getäuscht zu werden, ist die Schuld des anderen; zweimal ist es meine eigene. Von IBM lasse ich mich nicht noch einmal erwischen.
Fedora bleibt weiterhin das Testfeld für alles in CentOS und damit für alles in RHEL. Mich würde interessieren, welches Argument es dagegen gibt, künftige RHEL-Releases anhand einer „Zukunfts-Distribution“ wie Fedora zu modellieren.
Für alle, die den Linux-Kernel nicht aus der Nähe verfolgen: maddog ist eine Legende.
Seine Perspektive ist sehr interessant und begrüßenswert, besonders die Art, wie er das Thema historisch einordnet. Geschichte zu kennen hilft wirklich, den Kontext zu verstehen. Der Originaltext ist lang, aber lesenswert.
Ich bin etwa 30 Jahre jünger als Jon Hall und konnte seine Leistungen daher nicht direkt kennen, außer durch mündliche Überlieferungen und Texte. Er hat auch keinen Mega-Bestseller oder Software hinterlassen, die ich nutzen könnte (gut, es gibt Linux for Dummies), also sah ich immer wieder, dass Leute ihn eine Legende nannten, verstand aber nicht warum.
Schließlich fragte ich in der Linux-Kernel-Community nach und bekam erklärt, welchen Umfang seine Beiträge hatten. In gewisser Weise war er Linus’ Mentor. Als sie sich 1994 trafen, war Linus ein 25-jähriger Student und Jon ein 44-jähriger Marketing-Manager bei DEC. Ich stelle mir ihr Gespräch manchmal wie eine Szene vor: „Junge, hör mir gut zu. Das hier ist jetzt deine Aufgabe.“
Vor diesem Hintergrund fällt ein Satz in Jon Halls Wikipedia-Biografie auf. Dort heißt es, dass er während seiner Zeit bei Digital erstmals Interesse an Linux entwickelte und eine wichtige Rolle dabei spielte, Ausrüstung und Ressourcen zu beschaffen, damit Linus Torvalds die erste Portierung auf Digitals Alpha-Plattform durchführen konnte.
Auch eine Zeile in seinem LinkedIn-Lebenslauf zeigt dieselbe Perspektive. Senior Marketing Manager, DEC, 1983–1998: 1994 traf er Linus Torvalds, erkannte den kommerziellen Wert von Linux und beschaffte die Finanzierung, um Linux auf den 64-Bit-Alpha-Prozessor zu portieren, womit eine milliardenschwere Geschäftslinie für Linux-basierte Hochleistungs-Supercomputer eröffnet wurde.
WP: https://en.wikipedia.org/wiki/Jon_Hall_(programmer)
LI: https://www.linkedin.com/in/maddog/
Der Aussage, dass man „diejenigen, die diese Klone nutzen und der Community in keiner Form etwas zurückgeben, als ‚Trittbrettfahrer‘ sieht“, stimme ich zu — aber das ist etwas, das bei Freier Software ursprünglich bis zu einem gewissen Grad akzeptiert wurde. Etwas kostenlos bereitzustellen bedeutet eben auch, dass nicht alle etwas — oder überhaupt nichts — zurückgeben
Der Unterschied zu Dingen wie Oracle Awesome Linux ist, dass sie dort die von Red Hat geleistete Mehrwertarbeit und das Ökosystem als Service verkaufen. Im Grunde: „Wenn ihr dafür zusammen mit unseren anderen Produkten Support wollt, kauft das hier. Wir liefern es so aus, wie Red Hat es veröffentlicht.“
Meiner Ansicht nach zielt die Änderung von Red Hat eher darauf ab, Geschäftsmodelle wie ein proprietäres „Oracle Red Hat for X“ teurer zu machen. Wer sich RHEL für akademische Hochleistungsinfrastruktur nicht leisten konnte, kann es sich weiterhin nicht leisten und wählt einfach etwas anderes.
Hier wegen Fedora herumzukrähen bringt wenig. Fedora ist ein Projekt mit kommerziellem Zweck, das die Bedürfnisse des Unternehmens erfüllt, und es wird existieren, bis es eines Tages nicht mehr existiert.
Red Hat ist nicht Microsoft. Alle erkennen an, dass es viele Distributionen gibt, darunter auch viele gute. Man kann heute sofort eine Distribution starten. Aber „Na gut, dann nehmen wir eben Debian“ ist auch nicht unbedingt eine valide Antwort. Debian ist ein hervorragendes Projekt und Produkt, aber wenn man sich nicht deshalb für Red Hat entschieden hat, weil man 1998 eine Heft-CD bekommen hat, sondern aus anderen Gründen, dann ist Debian ohne viel Arbeit wahrscheinlich nicht ideal. Am Ende ist es eine Geldfrage zwischen den Kosten dafür, dass Menschen die Arbeit selbst machen, und den Kosten dafür, Red Hat damit zu beauftragen und die eigenen Leute andere Dinge tun zu lassen
Ich erinnere mich daran, früher dem Fedora-Projekt Server und Hosting gespendet zu haben. Beim Einrichten des Servers fragte ich den Zuständigen: „Sie wollen sicher RHEL laufen lassen?“ Er sagte „Ja“. Als ich fragte: „Haben Sie einen nutzbaren Lizenzschlüssel?“, antwortete er: „Ich könnte einen besorgen, aber das ist lästig, installieren Sie einfach CentOS.“
Der Dozent empfahl, für die Übungen nach dem Kurs CentOS zu verwenden (noch bevor CentOS übernommen wurde). In einem der späteren Projekte landeten wir dann letztlich doch bei Red Hat
Danach waren es CentOS und Klone, und eine Zeit lang schien es sogar, als meinten Leute eigentlich CentOS, wenn sie RHEL sagten.
Bei Qt ist es ähnlich. Selbst wenn fast die gesamte Software von Qt abhängt, bleiben sie bei Qt 4.x, um Digia kein Geld zahlen zu müssen
Als Red-Hat-Mitarbeiter weiß ich maddogs Perspektive zu schätzen. Ich wünschte, andere könnten ebenso breit sehen, was Unternehmen für Open Source tun.
Wenn man intern sieht, wie Arbeit entsteht, verändert das die Perspektive. Ich wünschte, wir könnten den Leuten vermitteln, was wir tatsächlich verkaufen. Wir verkaufen keine Software und keine Softwarelizenzen.
Wir umgehen keine Open-Source-Lizenzen, und wir ändern auch keine Lizenzen. Wir versuchen, unsere Leute weiterarbeiten zu lassen, die für Kunden wertvolle Arbeit leisten. Viel von dem, was wir tun, geht in Upstream-Projekte und wird mit Wettbewerbern, der Community und Nutzern geteilt
Es ist schön, solche großartigen historischen Geschichten von maddog zu hören. Als er einen der Austin-Besuche machte, von denen er in seinem Text spricht, arbeitete ich beim LTC, und ich hatte die Gelegenheit, beim Mittagessen mit ihm zu sprechen. Das ist ungefähr 20 Jahre her.
Es ist immer interessant zu hören, was jemand in den Siebzigern in seiner Laufbahn als „Wendepunkt“ betrachtet. Besonders eindrucksvoll ist auch, wie sich meine Wendepunkte mit ihren Wendepunkten verflechten.
Ich steckte mitten im SCO-Trubel, aber ich weiß nicht, ob ich über Teile davon sprechen darf. Vielleicht sind die Unternehmensanwälte inzwischen ausreichend im Ruhestand oder tot, sodass ich sagen kann, was ich sagen möchte. Falls ich die Motivation finde.
Ich freue mich, dass maddog seine Geschichten weiterhin teilt. Je älter ich werde, desto weniger Interesse habe ich daran, im Internet mit irgendwem irgendetwas zu teilen. Gespräche, die für mich Bedeutung haben, finden heutzutage fast nur noch persönlich statt, sodass es mir kaum lohnenswert erscheint, mit Menschen, die ich persönlich nicht kenne, etwas zu teilen oder mich einzubringen
Das Unternehmen, für das ich arbeite, wollte RHEL auf die von uns gebaute Hochleistungs-Serverhardware bringen, bekam aber einen Preis von etwa 1 Million US-Dollar pro Lizenz genannt, nicht verhandelbar. Dadurch wäre unser Produkt viel zu teuer geworden.
Also gingen wir letztlich zu CentOS und wechselten dann zu Rocky, und stellten ein Team von etwa 30 Leuten ein, um das zu verwalten (neben anderen Projekten). Ich respektiere Red Hat und ihr Recht, Software auf die von ihnen gewünschte Weise zu verwalten, aber nach den Erfahrungen der letzten Jahre fühlt es sich so an, als wollten sie so viel wie möglich aus der Marke herauspressen. Ich bin gespannt, wie es in den nächsten fünf Jahren weitergeht
Bei den Stellen „Ich begann 1969 mit dem Programmieren“ und „Tatsächlich war es nicht nur schwierig, Software zu verkaufen, man konnte auch kein Urheberrecht darauf anwenden“ frage ich mich, ob die Rechtslage 1969 tatsächlich so war. Stimmt es, dass Urheberrecht auf Software nicht anwendbar war?
Dass der Autor das 1969 so geglaubt hat, ist durchaus plausibel, aber ich frage mich, ob dieser Glaube rechtlich korrekt war.
Ich war damals nicht in der Rechtspraxis tätig, aber meinem überlieferten Verständnis nach war unklar, ob Urheberrecht auf Software anwendbar sein würde und, falls ja, wie. Kluge Akteure erwarteten jedoch im Allgemeinen, dass es über Geschäftsgeheimnisse hinaus irgendeine Form von Schutz für geschriebene Software geben würde.
Es gab allerlei Fragen, Theorien und Vorschläge dazu, ob das im Rahmen des Urheberrechts geschehen würde oder durch ein speziell für Software geschaffenes System. Die Antwort in den USA wurde klar, als „computer program“ in die Definition des Geltungsbereichs des Urheberrechts aufgenommen wurde. Wenn heute noch offene Streitfragen diskutiert werden, wird weiterhin CONTU zitiert, die Kommission, die diese Empfehlung vorangetrieben hat.
https://en.wikipedia.org/wiki/Software_copyright#History
Es ist seltsam, Jon Hall nicht zu glauben, aber irgendeinem Fremden in sozialen Medien schon.
Ich habe maddog um das Jahr 2000 herum bei einer Veranstaltung getroffen, die ich in Paris mitorganisiert habe. Wir stellten viele Fragen, und er gab aufschlussreiche Antworten. Manchmal verpackte er sie in lange Geschichten, ähnlich wie im verlinkten Text.
Am meisten in Erinnerung geblieben ist mir das hier: „Frage: Wie können wir Linux dabei helfen, über die paar Prozentpunkte hinaus, die es auf dem Desktop bereits hat, Marktanteile zu gewinnen?“
„Antwort: Das geht nicht. Suchen Sie einen Markt, der derzeit keine Computer nutzt, entwickeln Sie ein Produkt, das die Bedürfnisse dieses Markts erfüllt, und sorgen Sie dafür, dass dieses Produkt Linux verwendet. Denken Sie zum Beispiel an Smartphones.“
Schön zu sehen, dass maddog immer noch aktiv in FOSS involviert ist.
Irgendwann Ende der 90er auf der COMDEX in Chicago hat er mich und einen Freund überredet, ein paar Stunden lang seinen Stand zu betreuen, damit er sich die Ausstellung ansehen konnte. Ich weiß nicht mehr, ob es LPI, LI oder eine andere Linux-bezogene Organisation war. Ich glaube, wir verteilten Distributions-CDs und erklärten den Leuten Linux.
Das war diese verrückte Zeit, in der Linux die PC-Welt überrollte, und Tux war überall.