Redaktioneller Stand: 07.10.2026 · Deutschland
Komponenten und Fassungen vollständig erfassen
Erstellen Sie eine Übersicht eingebundener Bibliotheken, Werkzeuge und weiterer Bestandteile. Berücksichtigen Sie auch mittelbar verwendete Abhängigkeiten. Name, Version, Herkunft und Lizenz werden zusammen dokumentiert. Ein Paketname allein erklärt nicht, welche Fassung tatsächlich im Produkt steckt. Die technische Bestandsaufnahme sollte daher mit Build und Auslieferung abgeglichen werden. So bleibt erkennbar, welche Komponenten in der ausgelieferten Version enthalten sind und welche Lizenzangaben zur konkreten Verwendung gehören.
Die konkrete Lizenz und Nutzung lesen
Open Source ist kein einheitlicher Vertragstyp mit identischen Anforderungen. Prüfen Sie den tatsächlichen Lizenztext und seine Fassung. Interne Nutzung, Weitergabe und Betrieb als Dienst können unterschiedliche Fragen auslösen. Die Bezeichnung kostenlos bedeutet nicht, dass sämtliche Bedingungen entfallen. Auch gesetzliche Befugnisse werden berücksichtigt. Die Bewertung sollte daher den Nutzungsweg erklären und die einschlägigen Pflichten zuordnen, statt alle Komponenten allein nach ihrer freien Verfügbarkeit oder ihrem Bekanntheitsgrad freizugeben.
Hinweise und Dokumentation richtig bereitstellen
Je nach Lizenz können Lizenztexte, Urheberhinweise und Änderungskennzeichnungen erforderlich sein. Die Apache-Lizenz 2.0 enthält beispielsweise konkrete Bedingungen bei Weiterverbreitung einschließlich eines gegebenenfalls relevanten NOTICE-Dokuments. Prüfen Sie die tatsächlich nötigen Angaben und ihren vorgesehenen Ort. Ein allgemeiner Link auf eine Projektseite genügt nicht automatisch. Das Auslieferungsverfahren muss daher die passenden Unterlagen erzeugen und erhalten, damit erforderliche Informationen zusammen mit dem Produkt tatsächlich beim Empfänger ankommen.
Quellcodepflichten und Kombinationen bewerten
Bestimmte Lizenzen können unter ihren Voraussetzungen Pflichten zur Bereitstellung von Quellcode oder weitere Bedingungen enthalten. Ob diese greifen und welchen Umfang sie haben, hängt von Lizenz, Kombination und Nutzungsart ab. Weder jede Open-Source-Nutzung noch jede Verbindung verlangt automatisch die Veröffentlichung des gesamten eigenen Produkts. Die konkrete Architektur wird deshalb mit geeigneter fachlicher Unterstützung geprüft. Dokumentieren Sie die Entscheidung, bevor ein geändertes Produkt oder ein neues Vertriebsmodell freigegeben wird.
Beispiel: Bibliothek in ausgelieferter Anwendung
Ein Unternehmen verwendet eine Bibliothek unter Apache 2.0 in einer Kundenanwendung. Die Prüfung erfasst Version, Änderungen und vorhandene Hinweise. Anschließend werden die einschlägigen Lizenz- und Dokumentationsbedingungen in den Auslieferungsablauf aufgenommen. Andere enthaltene Komponenten werden eigenständig bewertet. Das Beispiel zeigt, warum eine einzelne freigegebene Lizenz nicht automatisch sämtliche Abhängigkeiten abdeckt und der konkrete Lieferumfang einschließlich erforderlicher Begleitinformationen vor dem Vertrieb nachvollziehbar geprüft werden sollte.
Freigabe bei Änderungen erneut prüfen
Benennen Sie Zuständigkeit für Lizenzprüfung, technische Bestandsliste und Auslieferung. Neue Versionen oder Vertriebswege werden erneut abgeglichen. Prüfen Sie außerdem Sicherheit und zugesagte Kundenrechte, die sich nicht allein aus der Open-Source-Lizenz ergeben. Ergebnis ist eine komponentenbezogene Freigabe mit umgesetzten Pflichten und nachvollziehbarer Dokumentation. Die Kontrolle verhindert, dass ein später eingebundener Bestandteil unter anderen Bedingungen unbemerkt mitverteilt wird oder eigene Vertragszusagen Rechte versprechen, die tatsächlich nicht eingeräumt werden können.
Checkliste für Ihre Vorbereitung
- Komponentenliste mit Versionen und Abhängigkeiten
- Konkrete Lizenztexte und Änderungshistorie
- Vertriebsmodell und technische Kombination
- Hinweise, Quellcodepflichten und Freigabeprozess
Ordnen Sie Dokumente nach Datum. Unklare Angaben werden als offen markiert; Originale und vollständige Anlagen helfen bei der konkreten Prüfung.
Häufige Fragen
Bedeutet Open Source völlig bedingungslose Nutzung?
Die einschlägigen Lizenzbedingungen und tatsächliche Nutzungsart sind zu prüfen.
Muss jedes eigene Produkt vollständig offengelegt werden?
Mögliche Quellcodepflichten hängen von der konkreten Lizenz und Verwendung ab.
Genügt die Prüfung einer Hauptbibliothek?
Auch weitere Bestandteile und Abhängigkeiten gehören in die Bestandsaufnahme.
Fachliche Einordnung
Grundlagen: § 69c UrhG; § 31 UrhG; Apache Software Foundation: Lizenz 2.0. Die allgemeinen Informationen ersetzen keine Prüfung Ihrer Unterlagen. Zuständigkeit und erforderliche Fristen werden im konkreten Auftrag geklärt.