© bowie15 / 123RF.com

Alles Open Source – oder? Wie Investoren und Angst vor Machtverlust Firmen zu Openwashing, Open Core und Commercial Open Source treiben.

Es geht um Geld, Macht und geistiges Eigentum: Mehr und mehr Firmen sehen sich durch Ausschreibungen, den Markt und Investoren genötigt, Open Source als Label auf ihre Fahnen zu schreiben. Gleichzeitig weigern sie sich, die Grundlagen des Modells umzusetzen oder zu verstehen.

Konzerne wie Red Hat scheinen ein legales Schlupfloch in Open-Source-Lizenzen gefunden zu haben: den Open-Source-Quelltext gar nicht zu publizieren. Es genügt ja, wenn die Kunden ihn bekommen. Doch sobald die ihn teilen, veröffentlichen oder verändern, endet das Kundenverhältnis, und sie erhalten weder Support noch Updates. Gemäß dem US-amerikanischen Rechtsprinzip Caveat Emptor [1] hat diesen Konzernen zufolge ein OSS-Vendor das Recht dazu. Die lateinische Phrase steht für “Hüte Dich, Käufer!”, auf Englisch “Buyer beware!”. Seit Red Hat den freien RHEL-Klon CentOS quasi beerdigte [2], indem man ihm die Quelltexte entzog, folgen mehr und mehr Unternehmen diesem Modell.

Die Open-Source-Community diskutiert derzeit heftig (bald auch auf der FOSDEM 2024), ob und wie sich die Lücke stopfen lässt. Es steht die Frage im Raum, ob es überhaupt legitim sei, hier noch von Open Source zu sprechen – obwohl doch offensichtlich kein Lizenzverstoß vorliegt. Dem stehen Bedenken gegenüber, die sich um Geschäftsmodelle drehen: “Wie soll man sonst mit Open Source noch Geld verdienen? Je besser der freigegebene Code, desto schlechter ist unser Umsatz, weil die Anwender unseren Support nicht mehr brauchen. Wir verlieren Millionen durch Trittbrettfahrer ohne Ahnung, die unseren OSS-Code stehlen, mangels Know-how scheitern und unsere Marke damit beschädigen.”

Wer sich schon länger mit freier und quelloffener Software beschäftigt, dem kommen die Bedenken bekannt vor. Seit Beginn der Revolution, die das GNU-Projekt, die GPL und der Erfolg von Linux in die IT-Welt brachten, stellt sich unaufhörlich die Frage, woher das Geld kommen soll, wenn man sein geistiges Eigentum veröffentlichen muss, wenn die Software sich vom Produkt zur Dienstleistung wandelt [3]. Der Siegeszug des Labels Open Source erschwert es Firmen außerdem, ohne Open-Source-Modell Ausschreibungen zu gewinnen. Wer heute noch proprietären Entwicklungsmodellen anhängt, braucht gute Rechtfertigungsgründe. Wer andererseits Open Source macht, braucht ein gutes Geschäftsmodell, um nachhaltig Gewinne zu generieren.

Viele gerade erst in der OSS-Welt angekommene Firmen tun sich schwer mit der neuerdings geforderten Offenheit. Nicht alle Player auf dem Markt folgen den Idealen, dem Geist und den Vorgaben der freien Software. Manche tricksen und versuchen zwar, Open Source in die eigene Kommunikation auf der Webseite oder in Kundengesprächen einzuführen, doch wenn Kunden, Anwender oder Journalisten Code suchen, finden sie nichts.

Phoenix und Azure-Cloud

Weder schrecken Anstalten des öffentlichen Rechts (AöR) vor derlei zurück, noch sind große OSS-Firmen davor gefeit. Wer mit “Wir machen Open Source” wirbt, aber die damit einhergehenden Regeln missachtet, betreibt Openwashing. Ein Consultant bringt es auf den Punkt: “Wenn ich auf der Webseite eines sogenannten Open-Source-Produkts keinen Link zu Github, Opencode oder ähnlichen Portalen finde, ist das erledigt – für solche Spielchen habe ich keine Zeit.” Zu groß ist die Wahrscheinlichkeit, dass hier nur das Marketing das Open-Source-Label aufgedruckt hat.

Die Open-Source-Mode treibt manchmal bizarre Blüten. Hersteller beanspruchen das Etikett für Ausschreibungen, obwohl sie “keinerlei geistiges Eigentum veröffentlichen werden.” Das gilt beispielsweise für die milliardenschwere Dataport, eine AöR und Hersteller der dPhoenix-Suite, einer Art freiem Office 365 für die öffentliche Verwaltung. Dort gab man auf mehrfache Nachfragen offensichtlich existierenden Code nicht heraus, verstrickte sich in Widersprüche und entfernte alle Referenzen auf der Webseite hinsichtlich eigener Open-Source-Software – obwohl der Auftrag für die Entwicklung genau das enthielt. Details dazu finden sich in einem Artikel des Linux-Magazins [4].

Schlechtes Vorbild

Richtig Fahrt nahm die Debatte um das Openwashing auf, als das Linux-Urgestein Red Hat 2021 die Community-Version von RHEL CentOS praktisch begrub, durch CentOS Stream ersetzte und Mitte 2023 den Zugriff auf CentOS Stream und den Quellcode [5] hinter ein Login für Red-Hat-Kunden verfrachtete. Das sperrte die schnell entstandenen CentOS-Forks wie Alma Linux oder Rocky Linux aus. Seit Sommer 2023 erhalten ausschließlich Kunden die Änderungen von Red Hat an Enterprise Linux.

Die ganze Geschichte von Red Hat, CentOS und CentOS Stream ist umfangreich. Suchen Sie auf Youtube nach Begriffen wie “Redhat goes closed source”, dann werden Sie schnell fündig [6]. Die CentOS-Community, Spinoffs und Forks wie Alma oder Rocky waren davon gleichermaßen betroffen, obgleich Alma sich kämpferisch gibt [7]. Es gibt schlicht keinen allgemein verfügbaren, aktuellen und vollständigen Quelltext für RHEL mehr. Nur noch Kunden bekommen Zugriff auf den Code der letzten RHEL-Version, geschützt per Login. Das Teilen oder Veröffentlichen untersagt der Hersteller (Abschnitt 1.2 g des “Product Appendix 1 Software and Support Subscriptions” [8]).

Was vermutlich Heerscharen an IBM- und Red-Hat-Anwälten wasserdicht geprüft haben, dürfte korrekt im Sinne der GPL und anderer Lizenzen sein (Abbildung 1). Die Policy widerspricht allerdings gängigen Definitionen, ebenso der von Red Hat selbst publizierten: “Open-Source-Software ist Code, der entworfen wurde, um öffentlich verfügbar zu sein, damit alle ihn inspizieren, verändern und verbessern können, wie sie es brauchen.” [9].

Abbildung 1: Die Definition von Open Source, die Red Hat auf seinen Webseiten veröffentlicht hat, scheint nicht zur neuen Firmenpolitik zu passen.

Das klingt sehr nach der offiziellen Definition der Open Standards Initiative [10], die freie Weitergabe, verfügbaren Quellcode und abgeleitete Arbeiten ausdrücklich benennt, und der Definition der vier essenziellen Freiheiten des GNU-Projekts [11]. Auf Nachfrage von Golem.de erklärte Red Hat erstaunlich offen: “Ja, wir veröffentlichen nicht mehr über https://git.CentOS.org, aber jeder unserer Kunden (bezahlend oder nicht) bekommt den Quelltext zu den Binärdateien von uns. […]+ Red Hat behält sich die Entscheidung vor, wer unsere Kunden sind. […] Bricht ein Kunde eventuell die Vertragsbedingungen der Subskription, dann kann Red Hat das Vertragsverhältnis beenden oder nicht verlängern.”

Zudem verweist Red Hat auf CentOS Stream (da finde sich der RHEL-Code), die eigene “Upstream-First”-Policy und die hauseigenen Source Containers [12] – Beispiele, wie sehr man “bei der Bereitstellung des Codes über die Anforderungen beispielsweise der GPL hinausgehe”. Sogar die eigenhändige, manuelle Pflege des Codes ist unerwünscht. “Die Kunden bezahlen Red Hat unter anderem für die Wartung des Codes – die Patches, Aktualisierungen und Optimierungen, die mit dem Betrieb einer Enterprise-Betriebssystemplattform einhergehen. Jederzeit kann ein Benutzer entscheiden, dass er das selbst tun möchte. Das ist auch völlig in Ordnung, denn die Software ist quelloffen. Dies bedeutet jedoch, dass Red Hat das Recht hat, die Geschäftsbeziehung zu beenden, wenn Kunden ihre Abonnementdienste für diese Arbeiten nutzen, und dass wir keine Garantien oder Support für diese vom Benutzer gewartete Software geben.”

Noch einmal: Eine Einschränkung auf Kunden ist wahrscheinlich lizenztechnisch und -rechtlich unbedenklich, aber gleichzeitig eine Absage an die Community. Man heißt deren Engagement zwar willkommen, doch die Oberhoheit möchte man selbst behalten. Aus betriebswirtschaftlicher Sicht ergibt das durchaus Sinn. Es ist jedoch nur notwendig, wenn das Geschäftsmodell von der Exklusivität des Zugriffs auf den Code abhängt – ganz wie bei proprietären Modellen: Viel Kathedrale, ganz wenig Basar.

Böse Trittbrettfahrer

Das Beispiel macht bereits Schule. Dataport hat vermutlich die Open-Source-Welt nicht ausreichend verstanden, sonst hätte der Anbieter sich in seinen Antworten auf Red Hat berufen. Andere Hersteller tun das, etwa die tschechische Firma Easy Software, die hinter dem Ticketsystem Easy Redmine steht, einem Fork von Redmine. “Nur die Kunden bekommen den Sourcecode”, erklärt ein Sprecher auf Nachfrage nach dem Quelltext einer Erweiterung. “Wir nennen das ‘Enterprise Open Source’.”

Redmine ist Open Source, Easy Redmine eine Enterprise-Version davon, die in Teilen proprietären Ansätzen wie dem Open-Core-Modell folgt. Seltsam: Die angefragte Erweiterung ist in einer Interpreter-Sprache geschrieben, muss also gar nicht kompiliert werden. Anders als bei Red Hat gibt es keinen Binärcode, also besitzt selbstverständlich jeder Kunde automatisch den kompletten Quellcode. Er darf ihn nur nicht weitergeben oder verändern, sonst macht er sich unerwünscht – ganz wie beim großen Vorbild Red Hat.

Ganz risikofrei ist ein Schritt in diese Richtung jedoch nicht: Mitte 2023 wollte Hashicorp, der US-Hersteller des Infrastrukturwerkzeugs Terraform, eine neue Lizenz einführen. Die überraschend kurze Business Source License (BSL [13]) sollte Trittbrettfahrer ausbremsen, indem sie jegliche kommerzielle Nutzung verbot. Doch “non-commercial” klingt einfacher, als es ist: Die Wikipedia verbannte nach langen Diskussionen alle mit derartigen Einschränkungen verbundenen Inhalte als non-free [14] und verweist auf massive Unklarheiten bei der Definition.

Erwartungsgemäß war die Community empört, die Trittbrettfahrer verbündeten sich, der Shitstorm war groß. Flugs gab es mit OpenTofu ein schlagkräftiges, mit Investmentkapital ausgestattetes Konkurrenzprodukt [15]. Hier liegt Openwashing vor, weil Open-Source-Definitionen in der Regel Einschränkungen bei der Verwendung der Software verbieten. Der Verlierer: ganz klar Hashicorp.

Auch die Amazon Web Services (AWS) profitieren massiv von freier Software. Dort misstraut man aber generell “von Herstellern gesteuerten Open-Source-Projekten”. Das sagte kein Geringerer als David Nalley im Interview mit The Register [16]. Er ist Direktor für Open Source Strategy und Marketing bei AWS und Präsident der Apache Software Foundation. Man arbeite bei AWS mit vielen Linux-Varianten, so Nalley, aber CentOS schien lange perfekt.

Amazon Linux basierte auf CentOS, dem Nalley eine “lebendige Community” attestierte, die “sich auch um die wichtigen Extra Packages for Enterprise Linux (EPEL) kümmerte”. Nach dem CentOS-Aus durch Red Hat stieg AWS auf Fedora um, obwohl die Community-Distribution keine ebenbürtigen EPEL-Repositories kennt: “Das ist ein Problem. Ich weiß nicht, ob es ein großes technisches Hindernis ist: Für die meisten dieser Programme kann man, wenn man den Quellcode hat, einfach eine andere Distribution erstellen. Ich war ja selbst früher Fedora-Paketierer”, erklärt Nalley. Man müsse sich halt selbst um alles kümmern, bis hin zu Security Fixes. Insgesamt erscheint der Weg bei AWS jedoch klar: “Jedes Unternehmen, das Open-Source-Software einsetzt, profitiert weit mehr, als es zurückgibt. Das ist eine universelle Wahrheit.”

Fazit

Openwashing, etwa nach dem Red-Hat-Modell, verhindert nicht nur eine effektive Community, es gleicht einem gravierenden Rückschritt. Am Ende entwickelt man wieder Software nach dem proprietären Modell, im stillen Kämmerlein, maximal als Open Core. Zusätzlich wirft das Argument, ein Hersteller könne sich seine Kunden aussuchen und niemand würde zu irgendetwas gezwungen, mehr Fragen auf, als es beantwortet. Schließlich könnte es sich keine Kommune oder Firma leisten, den Hersteller-Support zu verlieren. Ob das Caveat-Emptor-Konzept sich mit europäischer Herstellerhaftung verträgt, spielt dabei zunächst keine Rolle. Offenkundig haben einige OSS-Hersteller hier einen Weg gefunden, der zwar lizenzkonform mit GPL, GPLv3, EUPL und Co. erscheint, dem Geist von Open Source und freier Software aber diametral widerspricht.

Die Fans und Geldgeber der Open-Core-Richtung trafen sich Anfang Dezember 2023 zum Open Core Summit in den Docks von San Francisco. Dort sprachen Vertreter von Red Hat (IBM) und Github (Microsoft), man hob den Begriff Commercial Open Source (COSS) aus der Taufe. Der Co-Producer und OSS-Venture-Capital-Geber OSSC postulierte: “Open Source frisst die Software selbst schneller auf als die Software die Welt.” Das erinnert stark an das “Krebsgeschwür Linux”, das Ex-Microsoft-Chef Ballmer einst postulierte.

Für OSSC ist die Sache einfach: Wer Open Core macht, kommt leichter zu Investorenkapital, trotz Open Source – eben mit Commercial Open Source und voller Kontrolle. Vielleicht findet sich hier des Pudels Kern: Das Investmentkapital sucht Wege, die unberechenbare Open-Source-Welt in alte Geschäftsmodelle zu “stabilisieren” und sicherzustellen, dass nur die Firmen dahinter den Profit an der freien Software maximieren können. Die Open-Source-Welt sollte sich schleunigst Gedanken darüber machen, wie sie darauf reagiert (csi)