054.3 Lektion 1

Lizenzen für freie und Open Source Software müssen genauso ernst genommen werden wie andere Lizenzen und Verträge. Organisationen setzen sie durch, wie zum Beispiel die Software Freedom Conservancy, die im Namen kleiner Copyleft-Projekte handelt, die keine eigenen Prozesse zur Durchsetzung haben.

Für diese Organisationen sind gerichtliche Auseinandersetzungen in der Regel das letzte Mittel. Die meisten Verstöße sind unbeabsichtigt und lassen sich durch Aufklärung leicht beheben. Dennoch schadet es dem Ruf einer Organisation, wenn sie in Unkenntnis und unsensibel gegenüber der Community handelt, von deren Software sie abhängig ist.

Tatsächlich wurden schon Klagen eingereicht, wenn ein Benutzer der Software die Zusammenarbeit verweigert und die Software oder der Beklagte namhaft sind.

Selbst wenn ein Unternehmen nicht verklagt wird, kann der Schaden beträchtlich sein, den ein Lizenzverstoß für die Beziehung zur Community und den Ruf des Unternehmens bedeutet. Ein Projekt kann schon daran scheitern, dass Fragen von Entwicklern in den Foren, die der Software gewidmet sind, unbeantwortet bleiben.

Es kann verheerend sein, wenn jemand Copyleft-Software in einem proprietären Produkt findet. Um die Lizenz einzuhalten, müssen die Entwickler entweder den gesamten Copyleft-Code entfernen oder ihr Produkt unter der Copyleft-Lizenz freigeben. Die Freigabe der Software und die Bereitstellung des Quellcodes könnte fatale Auswirkungen auf Geschäftsmodelle haben, die auf Lizenzgebühren oder anderen Arten der Monopolisierung des Produkts basieren.

Wir haben gesehen, dass Lizenzverstöße großen Schaden anrichten können. Auch andere Verhaltensweisen, die das Vertrauen und den Ruf schädigen, bergen Risiken.

Manche Organisationen veröffentlichen Software unter einer freien oder Open-Source-Lizenz und kündigen dann irgendwann an, dass künftige Versionen unter einer proprietären Lizenz stehen werden. Dieser Wechsel kann verlockend sein, da viele Open-Source-Projekte nicht genügend finanzielle Unterstützung von Kunden erhalten.

Solche Lizenzänderungen sorgen jedoch sowohl bei Kunden als auch bei externen Entwicklern, die an dem Projekt mitarbeiten, für Unmut. Manchmal übernehmen externe Entwickler die freie Version und entwickeln sie unabhängig weiter, was als Forking bezeichnet wird. Die freie Version konkurriert dann mit der proprietären Version des Unternehmens und könnte Kunden abwerben.

Das Engagement in Projektforen birgt ebenfalls Risiken. Ein Unternehmen muss den dort angemessenen Auftritt lernen. Zu den häufigsten Problemen gehören:

Geschäftsmodelle werden in einer anderen Lektion behandelt; dieser Abschnitt weist lediglich auf finanzielle Risiken bei der Beteiligung an Open-Source-Projekten hin.

Unternehmen starten oder beteiligen sich an Open-Source-Projekten in der Erwartung, durch Support-Verträge, SaaS-Verträge, Datenerfassung oder sogar Spenden und Zuschüsse Einnahmen zu erzielen. Allerdings sind Open-Source-Projekte häufig weniger lukrativ als erhofft. Natürlich geht jedes Unternehmen mit einem neuen Projekt ein Risiko ein, aber im Open-Source-Umfeld sind zuverlässige Einnahmequellen besonders schwierig zu finden.

Open Source scheint am nachhaltigsten, wenn es andere Ertragsmodelle unterstützt, beipsielsweise den Verkauf von Hardware, Autos, Druckern usw.

Wie bereits beschrieben, sind die Mitglieder eines Projekts manchmal uneins über den Projektplan, die Leitung oder andere Aspekte und einige gründen ein alternatives Projekt auf derselben Codebasis. Ein solcher Fork kann auch von einer Organisation ausgehen, um eine spezialisierte Version der Software zu erstellen. Android nutzt beispielsweise eine spezialisierte Version von Linux, die von Google verwaltet wird. (Google leistet auch viele Beiträge zur Kernversion von Linux, die nicht immer übernommen werden.)

Organisationen können aus verschiedenen Gründen einen Fork erstellen: Die von ihnen an das Kernprojekt übermittelten Änderungen werden abgelehnt, weil andere Entwickler sie nicht wollen; bei einem Projekt unter einer permissiven Lizenz oder einem Projekt, das nur innerhalb der Organisation verwendet wird, sollen Änderungen geheim bleiben.

Das Risiko eines Forks besteht darin, dass die Entwickler des abgespaltenen Projekts nun für die Wartung des gesamten Produkts verantwortlich sind. Wenn zum Kernprojekt wichtige Bugfixes oder neue Funktionen hinzugefügt werden, müssen die Entwickler des Forks diese Änderungen duplizieren oder darauf verzichten. Je mehr Zeit vergeht und je weiter sich die Projekte voneinander entfernen, desto schwieriger wird es, mit den Änderungen des Kernprojekts Schritt zu halten.

Wie bereits erläutert, enthalten einige Lizenzen für freie und Open Source Software inkompatible Klauseln, so dass solche Komponenten nicht zusammen in einem Produkt verwendet werden können.

Dieses Problem tritt häufig bei Fusionen oder Übernahmen auf: Jedes Unternehmen hat möglicherweise Software mit einer bestimmten Lizenz verwendet, und um den Code in ihren Projekten zu kombinieren, müssen sie sicherstellen, dass die Lizenzen kompatibel sind.

Viele Open-Source-Softwarelizenzen (wie auch die Nutzungsbedingungen für viele proprietäre Software und Dienste) schließen ausdrücklich jegliche Haftung für die Nutzung der Software aus, oder anders ausgedrückt: Die Lizenz oder die Nutzungsbedingungen bieten keine Garantie oder Gewährleistung.

Softwarehersteller werden für Probleme mit ihrer Software selten zur Verantwortung gezogen, dennoch klagen Kunden gelegentlich. Gerichte müssen Klauseln zum Ausschluss von Gewährleistung nicht in jedem Fall anerkennen.

Gesetze und Vorschriften erlegen den Entwicklern von Software immer mehr Verantwortung auf. Diese rechtlichen Beschränkungen — oder zumindest Vorschläge für Beschränkungen — sind derzeit vor allem im Bereich der künstlichen Intelligenz (KI) zu beobachten, sind aber manchmal auch weiter gefasst.

Viele Länder schränken die Ausfuhr von Waren und Software ein. Bei Software gelten solche Vorschriften vor allem für Sicherheitsprodukte und insbesondere für die Verwendung von Kryptografie. In den Vereinigten Staaten gab es früher strenge Kontrollen für Software, die Kryptografie enthielt, aber die Bestimmungen wurden für Open-Source-Projekte gelockert.

Unternehmen sollten die Ausfuhrbestimmungen des Landes, in dem sie Software entwickeln, kennen; diese Bestimmungen können den Vertrieb ihrer Produkte betreffen.

Da in IT-Umgebungen enorme Mengen (manchmal Zehntausende) von Komponenten verwendet und häufig geändert werden, müssen SBOMs extrem gut strukturiert sein, um Informationen automatisiert und schnell auslesen zu können. Hier geht es um zwei der beliebtesten Formate in der Open-Source-Welt:

Sowohl SPDX als auch CycloneDX erstellen hierarchische Strukturen in verschiedenen Formaten, darunter JSON und XML. Für jeden Standard gibt es zahlreiche Tools, sowohl zur Erstellung der Formate als auch zum Scannen der erstellten Dateien nach Informationen. Beliebte Websites zur Versionskontrolle ermöglichen es Entwicklern, mit einem Mausklick eine SBOM in einem dieser Formate zu erstellen.

Um die von einer Organisation eingesetzte Software bewerten zu können, benötigt man Informationen, woher sie stammt, welche Schwachstellen sie enthält, welche Lizenzen sie verwendet und andere Details. Diese Aufgabe wird als Software Composition Analysis (SCA) bezeichnet, und es gibt zahlreiche Tools, die anspruchsvolle Scans von SBOMs und der Software selbst durchführen.

Einige Tools extrahieren Lizenzinformationen, mit deren Hilfe ein Unternehmen entscheiden kann, ob die Software sicher in ein Produkt integriert werden kann und ob verschiedene Komponenten kompatible Lizenzen haben. Einige Tools vergleichen sogar Codeschnipsel mit Bibliotheken gängiger Open-Source-Projekte, um herauszufinden, ob Code aus den Open-Source-Projekten ohne korrekte Namensnennung übernommen wurde.

Der Einsatz dieser Tools ist vor allem bei Fusionen oder Übernahmen von entscheidender Bedeutung: Das übernehmende Unternehmen könnte feststellen, dass die Software, die es erwerben möchte, weniger wertvoll ist als erwartet, weil sie Open-Source-Komponenten enthält, die Anforderungen stellen, die die beabsichtigte Verwendung im neuen Unternehmen beeinträchtigen.

Organisationen können von Open Source Software und der Mitwirkung daran profitieren, müssen dabei aber ihre eigenen Interessen schützen und gleichzeitig Open-Source-Projekte unterstützen. Es sollte daher Richtlinien geben, die folgende Aspekte berücksichtigen:

Das OSPO koordiniert die Erstellung dieser Richtlinien und unterstützt bei der Einhaltung der Vorgaben.

Open-Source-Projekte müssen sicherstellen, dass die Beiträge rechtmäßig sind, dass zum Beispiel der Code nicht von einem proprietären Produkt oder einem Open-Source-Projekt mit einer inkompatiblen Lizenz übernommen wurde. Viele Open-Source-Projekte verlangen von Entwicklern darum die Zustimmung zu einem Contributor License Agreement (CLA), also einer Lizenzvereinbarung, um die Legitimität ihres Beitrags sicherzustellen.

Entwickler in einem Unternehmen, die zu diesen Projekten beitragen, könnten die Anwälte des Unternehmens bitten, die CLA zu prüfen und zu genehmigen. Die Anwälte sollten daher die Bedeutung der Klauseln in CLAs verstehen und darauf vorbereitet sein, sie zu überprüfen.

Viele CLAs standen aufgrund ihrer Komplexität in der Kritik und weil sie Schlupflöcher ließen, die es Projekten erlaubten, beigetragenen Code anders als von den Beitragenden gewünscht zu nutzen.

Viele Projekte verlangen von Entwicklern anstelle eines CLA daher die Unterzeichnung eines kurzen Dokuments, das als Developer Certificate of Origin (DCO) bezeichnet wird. Es bescheinigt, dass der Entwickler das Recht hat, den Code beizusteuern. Das DCO wird in der Regel nicht einem Anwalt zur Prüfung vorgelegt.

Einige Projekte bitten die Mitwirkenden auch einfach darum, das Urheberrecht bzw. die Nutzungsrechte an ihrem Code in einem Copyright Assignment Agreement (CAA) auf das Projekt zu übertragen. Viele Mitwirkende lehnen diese Praxis jedoch ab, weil sie den Code dann nicht mehr in eigenen Projekten verwenden können und dies dem Projekt die Kontrolle überlässt.

Open-Source-Projekte vereinen soziale, technische, rechtliche und organisatorische Aspekte. Derzeit ist das Bewusstsein für diese Faktoren in vielen Organisationen noch nicht so ausgeprägt, dass alle Manager, Entwickler, Anwälte usw. sie umfassend verstehen. Daher profitieren Organisationen sehr von der Einrichtung eines Open Source Program Office (OSPO) als zentrale Stelle für Interessenvertretung, Politikgestaltung, Durchsetzung von Richtlinien und Aufklärung.

Als eine Art Allzweckabteilung können OSPOs viele Aufgaben erfüllen, wie zum Beispiel:

Es gibt zahlreiche Dokumente und Online-Ressourcen zur Einrichtung eines OSPO. Kleine Organisationen können dafür auch Dritte beauftragen, die sich auf diesem Gebiet spezialisiert haben.