Können Sie diese selbstgehostete Anwendung für Ihr Unternehmen nutzen? Eine Due-Diligence-Checkliste für Open-Source-Lizenzen
Selbsthosting kann verändern, wie eine Anwendung betrieben wird, beantwortet aber nicht automatisch Fragen zu Lizenzen, Weitergabe, Marken oder Quellcode-Offenlegung. Nutzen Sie diese praxisnahe Checkliste, um Nachweise zusammenzutragen, Ihre geplante Nutzung zu definieren und zu erkennen, wann qualifizierte Rechtsberatung erforderlich ist.
Selbsthosting beantwortet nicht jede Lizenzfrage
„Open Source“ ist keine einheitliche Berechtigungsstufe, und der Zugang zu einem öffentlichen Quellcode-Repository reicht nicht aus, um zu klären, ob ein Unternehmen eine Anwendung in der beabsichtigten Weise nutzen, verändern, hosten, unter eigener Marke anbieten oder weitergeben darf. Die Open Source Initiative (OSI) trifft diese Unterscheidung ausdrücklich: Open Source betrifft die Bedingungen der Weitergabe ebenso wie den Zugang zum Quellcode.
Wenn eine Anwendung tatsächlich unter einer OSI-konformen Open-Source-Lizenz steht, darf diese Lizenz die Nutzung in einem bestimmten Tätigkeitsbereich, einschließlich der geschäftlichen Nutzung, nicht beschränken. Das ist hilfreich, beendet die Prüfung jedoch nicht. Ihre Bereitstellung kann separat lizenzierte Komponenten, Assets oder Plugins enthalten; Ihre geplante Tätigkeit kann eine Weitergabe umfassen; und Namen, Logos und Domains können durch Markenregeln statt durch die Softwarelizenz geregelt sein.
Betrachten Sie diesen Artikel als operativen Rahmen für die Due Diligence und nicht als Rechtsberatung. Das Ziel besteht darin, Annahmen durch überprüfbare Dokumentation zu ersetzen und die Situationen zu erkennen, in denen vor der Bereitstellung qualifizierte Rechtsberatung angebracht ist.
- Setzen Sie „Source Available“ nicht mit „Open Source“ gleich.
- Setzen Sie internes Hosting nicht mit der Erlaubnis gleich, Kopien an Kunden oder Auftraggeber weiterzugeben.
- Gehen Sie nicht davon aus, dass eine Lizenz im obersten Repository-Verzeichnis jedes Element der Bereitstellung abdeckt.
- Prüfen Sie Marken- und Namensregeln getrennt von den Bedingungen der Softwarelizenz.
Beginnen Sie mit der beabsichtigten Nutzung, nicht mit der Funktionsliste der Anwendung
Bevor Sie Lizenztexte lesen, halten Sie fest, was Ihre Organisation tatsächlich tun wird. Lizenzfragen werden klarer, wenn sie an ein konkretes Bereitstellungs- und Weitergabemodell geknüpft sind, statt an den allgemeinen Wunsch, „die Software kommerziell zu nutzen“.
Ein Tool, das nur von eigenen Mitarbeitenden genutzt wird, stellt einen anderen Sachverhalt dar als ein kundenseitiger Dienst, eine angepasste Bereitstellung für einen Auftraggeber oder ein Produkt, das die Anwendung zur Weitergabe bündelt. Dieselbe Unterscheidung ist relevant, wenn Sie ein Docker-Image, ein Installationsprogramm, einen veränderten Quellcodebestand oder eine verwaltete Instanz an Dritte bereitstellen wollen.
Formulieren Sie diese Aussage so konkret, dass eine Kollegin oder ein Kollege sie anhand der Lizenz prüfen kann. Ändert sich die beabsichtigte Nutzung später, öffnen Sie die Prüfung erneut, statt sich auf die frühere Schlussfolgerung zu verlassen.
- Internes Tool: Wer kann darauf zugreifen, und wird das Team es verändern?
- Kundenseitiger Dienst: Werden externe Nutzer remote mit der Anwendung interagieren?
- Bereitstellung für Auftraggeber: Übergeben Sie eine Kopie, ein Image, Quellcode oder einen veränderten Build?
- Weitergegebenes Produkt: Bündeln Sie die Anwendung oder wesentliche Komponenten in Ihrem eigenen Angebot?
- Markenauftritt: Werden Sie den Projektnamen, das Logo oder einen ähnlichen Namen in einem Produkt, Dienst oder einer Domain verwenden?
- Integration: Welche Plugins, Bibliotheken, Modelle, Schriftarten, Themes, Konnektoren und Assets werden einbezogen?
Finden Sie maßgebliche Lizenznachweise und halten Sie die geprüfte Version fest
Beginnen Sie mit Primärnachweisen für genau die Anwendungsversion, die Sie bereitstellen möchten. Die LICENSE-Datei eines Repositorys ist ein wichtiger Ausgangspunkt, sollte jedoch zusammen mit der Quellcode-Distribution, der Dokumentation des Anbieters oder Projekts, Urheberrechtsvermerken und beigefügtem LICENSE- oder NOTICE-Material geprüft werden.
Dokumentieren Sie die Release-Version, sofern zutreffend den Image-Tag oder den von Ihnen geprüften Source-Commit. Eine Lizenzbewertung ohne Versionsbezug lässt sich nur schwer erneut beurteilen, wenn ein Upgrade Abhängigkeiten, Hinweise oder Weitergabematerialien verändert.
Wenn eine Anwendung ohne Quellcode ausgeliefert wird, ist auch die OSI-Definition relevant: Bei einer Open-Source-Lizenz ist der Quellcode die bevorzugte Form für Änderungen, und die Weitergabebedingungen müssen eine gut bekannt gemachte Möglichkeit vorsehen, ihn zu erhalten, sofern der Quellcode nicht mit dem Produkt ausgeliefert wird. Schließen Sie nicht allein aus dem Vorhandensein eines Repositorys darauf, dass ein Projekt OSI-konform ist.
- Erfassen Sie die Quell-URL und das Zugriffsdatum.
- Speichern oder verlinken Sie den genauen Lizenztext und, falls angegeben, seine Kennung.
- Dokumentieren Sie Anwendungsversion, Release-Referenz oder Commit.
- Prüfen Sie auf LICENSE, COPYING, NOTICE, Urheberrechts-Header und Hinweise zu Drittanbietern.
- Vergleichen Sie Repository-Nachweise mit offizieller Dokumentation und verteilten Artefakten.
- Halten Sie Widersprüche, fehlende Dateien und unklare Herkunft als offene Fragen fest.
Lesen Sie den Umfang der Lizenz, bevor Sie Anwendungen vergleichen
Wählen Sie eine Anwendung nicht anhand ihres Funktionsumfangs aus und behandeln Sie die angegebene Lizenz als Fußnote. Lesen Sie den anwendbaren Text für das Werk, das Sie nutzen werden, insbesondere Bestimmungen zu Änderungen, Vervielfältigung, Weitergabe, Hinweisen, Patenten und Marken.
Die Apache License 2.0 enthält beispielsweise ausdrückliche Bedingungen für die Vervielfältigung und Weitergabe von Kopien oder abgeleiteten Werken. Dazu gehören die Bereitstellung einer Kopie der Lizenz, die Kennzeichnung veränderter Dateien, die Beibehaltung relevanter Hinweise und die Erhaltung anwendbarer Zuschreibungen aus der NOTICE-Datei. Diese Anforderungen sind an Vervielfältigung und Weitergabe gebunden. Eine zutreffende Bewertung hängt daher davon ab, ob Ihr geplantes Bereitstellungsmodell diese Handlungen umfasst.
Lizenzbezeichnungen ersetzen keine Analyse einer geplanten Kombination. Die GNU GPL FAQ beschreibt Lizenzkompatibilität danach, ob die betreffenden Lizenzen die beabsichtigte Kombination erlauben, und weist darauf hin, dass die Form der Kombination relevant sein kann. Wenn Ihr Angebot Komponenten auf eine Weise kombiniert, die nicht eindeutig dokumentiert ist, ist das ein Grund innezuhalten, statt zu raten.
- Bestimmen Sie das abgedeckte Werk: die Anwendung, ein Plugin, eine Bibliothek, ein Container-Image oder ein anderes Artefakt.
- Bestimmen Sie Ihre Handlungen: ausführen, verändern, kopieren, weitergeben, paketieren, an einen Auftraggeber bereitstellen oder remote zugänglich machen.
- Lesen Sie Bedingungen und Ausnahmen im vollständigen Lizenztext, nicht nur in einer Zusammenfassung.
- Listen Sie erforderliche Hinweise, Quellcode-Angebote oder Kennzeichnungen von Änderungen auf, die für Ihr Modell gelten könnten.
- Kennzeichnen Sie unsichere Komponentenkombinationen zur Prüfung durch Spezialisten.
Prüfen Sie Abhängigkeiten, Plugins, Modelle, Schriftarten und gebündelte Assets separat
Eine Lizenzdatei auf oberster Anwendungsebene klärt möglicherweise nicht die Rechte für alles, was Ihre Nutzer erreicht oder in Ihrem Build enthalten ist. Die Lizenzleitlinien von Apache erkennen beispielsweise an, dass Werke Dritter in einem Projektprodukt enthalten sein können und deren Lizenztexte in LICENSE- oder NOTICE-Dateien erscheinen oder separat verfügbar sein können.
Erstellen Sie ein Verzeichnis dessen, was tatsächlich bereitgestellt wird, und nicht nur dessen, was im Stammverzeichnis des Repositorys erscheint. Berücksichtigen Sie Laufzeitabhängigkeiten, Build-Abhängigkeiten, die in einem Artefakt ausgeliefert werden, aktivierte optionale Plugins, Themes, Schriftarten, Datensätze, Modelldateien und andere gebündelte Assets. Gehen Sie nicht davon aus, dass für all diese Elemente dieselben Bedingungen gelten wie für die Hauptanwendung.
SPDX ist als Vokabular für die Dokumentation und als SBOM-Format nützlich. Zu seinen Beziehungskonzepten gehören Abhängigkeiten, Abhängigkeitsmanifeste, Build-Abhängigkeiten, Entwicklungsabhängigkeiten und Laufzeitabhängigkeiten. Sie benötigen vor einer Entscheidung kein perfektes automatisiertes Verzeichnis, aber genügend Nachweise, um Komponenten zu identifizieren, die Ihre beabsichtigte Nutzung wesentlich beeinflussen.
- Erstellen Sie für jede wesentliche Abhängigkeit oder jedes gebündelte Element einen Komponenteneintrag.
- Dokumentieren Sie Komponentenname, Version, Quelle, Lizenznachweis und die Art, wie die Komponente in den Stack gelangt.
- Unterscheiden Sie Laufzeitkomponenten von reinen Build- und Entwicklungsbestandteilen.
- Prüfen Sie aktivierte Plugins und Erweiterungen getrennt von ungenutzten Optionen.
- Achten Sie auf beigefügte Hinweise, Lizenztexte und Anforderungen an Urheberbenennungen.
- Markieren Sie unbekannte oder individuelle Komponenten als Hindernisse, wenn sie ausgeliefert, verändert oder Auftraggebern zugänglich gemacht werden.
Halten Sie Entscheidungen zu Marken, Branding und Domains getrennt
Eine Softwarelizenz ist keine pauschale Erlaubnis, Projektnamen, Logos oder Branding beliebig zu verwenden. Die Markenprüfung verfolgt einen anderen Zweck: Verwechslungen über Herkunft, Zugehörigkeit oder Befürwortung zu vermeiden.
Die Richtlinie von Apache veranschaulicht diese Trennung. Sie bezeichnet Projektnamen, Produktnamen und Logos als Marken, während die Software selbst gemäß ihren Softwarelizenzbedingungen vertrieben wird. Speziell bei Apache-Projekten sollten abgeleitete Werke keine zum Verwechseln ähnlichen Projektnamen oder Projektlogos verwenden, und eine verwechslungsfähige Nutzung von Apache-Marken in Domainnamen erfordert eine schriftliche Genehmigung.
Nutzen Sie, sofern verfügbar, die eigene Markenrichtlinie des Projekts. Wenn Sie den Anwendungsnamen in einem Kundenangebot verwenden, ein Logo verändern, einen gebrandeten Fork veröffentlichen oder eine verwandte Domain registrieren wollen, nehmen Sie diesen Plan in das Nachweisverzeichnis auf und holen Sie Rat ein, wenn die Richtlinie ihn nicht eindeutig abdeckt.
- Wird der öffentlich sichtbare Dienst den Projektnamen oder das Projektlogo verwenden?
- Werden Sie den Dienst als offiziell, verbunden oder befürwortet darstellen?
- Wird ein veränderter Fork bestehendes Branding beibehalten, ersetzen oder ergänzen?
- Enthält die geplante Domain den Namen des Projekts oder der Organisation?
- Veröffentlicht das Projekt eine Markenrichtlinie oder Hinweise zur Markennutzung?
- Könnte die beabsichtigte Darstellung für Nutzer verwirrend sein?
Verstehen Sie Fragen zu Netzwerkdiensten und Quellcode-Offenlegung präzise
Gehen Sie nicht davon aus, dass die Bereitstellung von Software über ein Netzwerk immer dieselbe Wirkung hat wie die Weitergabe einer Kopie. GPLv3 stellt fest, dass die bloße Interaktion mit einem Nutzer über ein Computernetzwerk ohne Übertragung einer Kopie nach diesem Lizenztext für sich genommen kein „conveying“ ist.
AGPLv3 enthält eine andere, bedingte Bestimmung für eine veränderte Version, die Remote-Interaktion über ein Netzwerk unterstützt. Abschnitt 13 verpflichtet denjenigen, der die Änderung vornimmt, Remote-Nutzern die Möglichkeit anzubieten, den Corresponding Source dieser veränderten Version zu erhalten. Dies ist kein Grund, weitreichende Aussagen über jede gehostete Bereitstellung zu treffen; vielmehr ist es ein Grund, die genaue Lizenz, die Frage, ob Sie das abgedeckte Programm verändert haben, und die Unterstützung von Remote-Interaktion zu bestimmen.
Wenn Ihr Dienst mehrere Komponenten umfasst, analysieren Sie die Lizenz der jeweiligen Komponente und die Art der Integration. Die GNU GPL FAQ weist darauf hin, dass die Grenze zwischen getrennten Programmen und einem kombinierten Programm letztlich eine Rechtsfrage ist. Eine nicht offensichtliche Architektur ist kein Ort für eine beiläufige Compliance-Schlussfolgerung.
- Stellen Sie fest, ob eine remote zugängliche Komponente Bedingungen mit Bestimmungen zur Netzwerkinteraktion unterliegt.
- Dokumentieren Sie, ob Ihr Team diese Komponente verändert hat und wo sich die Änderungen befinden.
- Bestimmen Sie, ob Nutzer eine Kopie erhalten, nur mit einem Dienst interagieren oder beides tun.
- Dokumentieren Sie, wie Quellcode-Zugang, Hinweise und Änderungsdokumentationen bereitgestellt würden, falls erforderlich.
- Eskaliieren Sie unsichere Kombinationen, Forks und Pflichten zur Quellcode-Offenlegung vor dem Start.
Erstellen Sie vor der Bereitstellung ein Nachweisverzeichnis
Ein kompaktes Nachweisverzeichnis macht die Lizenz-Due-Diligence zu einer operativen Kontrolle. Es sollte einer anderen Person ermöglichen zu verstehen, was geprüft wurde, woher die Nachweise stammen, was die Organisation vorhat und was noch ungeklärt ist.
Bewahren Sie das Verzeichnis zusammen mit dem Bereitstellungsprotokoll auf und aktualisieren Sie es, wenn Sie die Anwendungsversion ändern, ein neues Plugin aktivieren, Code verändern, ein Image wechseln, ein Modell zur Auslieferung an Auftraggeber hinzufügen oder das öffentliche Branding ändern. Das ist hilfreicher als eine einmalige Ja-oder-Nein-Aussage, da sich selbstgehostete Stacks weiterentwickeln.
Nutzen Sie, sofern verfügbar, Standardkennungen und SBOM-Informationen, aber lassen Sie nicht zu, dass eine vertraute Kennung die Prüfung des anwendbaren Texts, der Hinweise und des Bereitstellungsmodells ersetzt.
- Name der Anwendung oder Komponente.
- Geprüfte Version, Release, Image-Referenz oder Commit.
- Quell-URL und Fundstelle des Lizenznachweises.
- Angegebene Lizenzkennung und Link zum vollständigen Text.
- Beobachtungen zu Urheberrecht, NOTICE und Zuschreibungen.
- Hinweise zu Abhängigkeiten und Beziehungen, einschließlich Laufzeit- und Build-Bestandteilen.
- Vorgenommene, geplante oder übernommene Änderungen.
- Plan für Weitergabe, Übergabe an Auftraggeber und Remote-Dienst.<br>Plan für Marke, Logo und Domain.<br>Offene Fragen, verantwortliche Person, Eskalationsentscheidung und Prüfdatum.
Häufige Fragen
Bedeutet Selbsthosting einer Anwendung, dass wir sie kommerziell nutzen können?
Nicht automatisch. Eine OSI-konforme Open-Source-Lizenz darf die Nutzung in einem bestimmten Tätigkeitsbereich, einschließlich der geschäftlichen Nutzung, nicht beschränken. Sie müssen jedoch weiterhin überprüfen, ob die genaue Anwendung und ihre Komponenten den angegebenen Bedingungen unterliegen, und Weitergabe, Änderungen, Hinweise, Marken sowie Ihren konkreten Bereitstellungsplan gesondert bewerten.
Ist ein öffentliches Git-Repository ein ausreichender Nachweis dafür, dass eine Anwendung Open Source ist?
Nein. Die OSI erläutert, dass Open Source mehr bedeutet als Zugang zum Quellcode; die Weitergabebedingungen müssen der Open Source Definition entsprechen. Prüfen Sie die maßgeblichen Lizenznachweise für die Version, die Sie verwenden möchten.
Müssen wir Abhängigkeiten prüfen, wenn die Anwendung eine LICENSE-Datei hat?
Ja. Werke Dritter können separate Lizenztexte oder Hinweise haben. Erfassen Sie wesentliche Laufzeitabhängigkeiten, ausgelieferte Build-Ausgaben, Plugins, Modelle, Schriftarten, Themes und gebündelte Assets und dokumentieren Sie dann deren Lizenznachweise und Rolle im bereitgestellten Stack.
Zählt das Hosting von GPL-Software für Nutzer automatisch als Weitergabe?
GPLv3 besagt, dass die bloße Netzwerkinteraktion ohne Übertragung einer Kopie kein conveying ist. Das genaue Ergebnis hängt von der anwendbaren Lizenz, der Komponente und dem ab, was Sie tatsächlich bereitstellen. Verallgemeinern Sie diese Aussage nicht auf jede Lizenz oder Architektur.
Was ist bei AGPLv3 für einen gehosteten Dienst anders?
Abschnitt 13 der AGPLv3 enthält eine bedingte Verpflichtung für eine veränderte Version, die Remote-Interaktion über ein Netzwerk unterstützt: Remote-Nutzern muss deutlich Zugang zum Corresponding Source der veränderten Version angeboten werden. Stellen Sie fest, ob Sie das abgedeckte Programm verändert haben, und holen Sie qualifizierten Rat ein, wenn die Anwendung der Verpflichtung unklar ist.
Können wir den Projektnamen und das Logo in unserem gehosteten Dienst verwenden?
Das ist eine Marken- und Brandingfrage, die von der Softwarelizenz getrennt zu beurteilen ist. Prüfen Sie die Markenrichtlinie des Projekts, insbesondere bevor Sie ein Logo verwenden, einen veränderten Fork vermarkten, eine Verbindung zum Projekt behaupten oder eine verwandte Domain registrieren.
Quellen und weiterführende Literatur
- The Open Source Definition — Open Source Initiative
- Apache License, Version 2.0 — Apache Software Foundation
- Apache Licensing and Distribution FAQ — Apache Software Foundation
- SPDX Overview — SPDX
- SPDX Specification: Relationships Between SPDX Elements — SPDX
- GNU Affero General Public License v3 — GNU Project / Free Software Foundation
- GNU General Public License v3 — GNU Project / Free Software Foundation
- GNU GPL FAQ — GNU Project / Free Software Foundation
- Apache Software Foundation Trademark Policy — Apache Software Foundation
- Docker Compose documentation — Docker