Open-Source-Komponenten der Zielgesellschaft: Lizenzinventar und Copyleft-Risiko

Ein Lizenzinventar sollte mindestens Paketname, konkrete Version, Herkunft, SPDX-Bezeichnung, Lizenzdatei, Copyright-Hinweise, Abhängigkeiten und die Verwendung im Produkt enthalten. Eine SBOM kann diese Daten liefern oder vorbereiten, ersetzt aber nicht die Prüfung des tatsächlich ausgelieferten Artefakts.

Abzugleichen sind insbesondere Manifestdateien, Lockfiles, Build-Images, Container, Plugins, vendorte Bibliotheken und Quellcode-Repositories. Fehlt eine Lizenzdatei oder weicht die verwendete Version vom Verzeichnis ab, ist die offene Frage im Datenraum sichtbar zu machen.

Die MIT-Lizenz erlaubt Nutzung, Bearbeitung und Weitergabe grundsätzlich weit, verlangt aber den Erhalt des Copyright- und Lizenzhinweises. Die Apache-Lizenz 2.0 enthält neben Nutzungs- und Weitergaberechten unter anderem Vorgaben zu Lizenztext, Änderungsvermerken, Copyright- und NOTICE-Hinweisen sowie eine gesondert formulierte Patentlizenz. Diese Pflichten müssen im Produkt und in den Vertriebsunterlagen auffindbar bleiben.

Die GPL 2.0 knüpft ihre zusätzlichen Anforderungen an das Kopieren, Bearbeiten und Weitergeben des Programms oder eines darauf beruhenden Werks. Bei der Weitergabe von Objektcode verlangt sie grundsätzlich den entsprechenden maschinenlesbaren Quellcode oder eine zulässige Alternative. Die AGPL 3.0 enthält zusätzlich Regeln für geänderte Programme, die Nutzer über ein Netzwerk verwenden können. Ob diese Regeln eingreifen, hängt immer vom konkreten Lizenztext, der Bearbeitung und der technischen Bereitstellung ab. Ein bloßer Lizenzname erlaubt keine pauschale Schlussfolgerung.

Für jede auffällige Komponente ist zu klären, ob sie unverändert, angepasst, statisch oder dynamisch eingebunden, als eigenständiger Dienst betrieben oder nur neben dem Produkt verteilt wird. Die Bezeichnung „Bibliothek“ oder „Microservice“ beantwortet diese Frage nicht. Auch die konkrete Form der Kommunikation und das gemeinsame Werk müssen technisch und urheberrechtlich eingeordnet werden.

Beim SaaS-Betrieb ist zusätzlich zwischen bloßer Nutzung auf dem Server und einer Weitergabe an Kunden zu unterscheiden. Bei AGPL-Komponenten ist die Netzwerkbereitstellung besonders aufmerksam zu prüfen. Die Richtlinie 2009/24/EG und das österreichische Urheberrechtsgesetz bilden den urheberrechtlichen Rahmen für Computerprogramme; die konkreten Pflichten des Projekts folgen dennoch aus dem jeweiligen Lizenztext und der tatsächlichen Nutzung.

Nicht jede Abweichung verlangt dieselbe Lösung. Möglich sind die Entfernung oder der Austausch einer Komponente, ein Upgrade auf eine passende Version, die Trennung eines Dienstes, die Einhaltung der Notice- und Quellcodepflichten oder der Erwerb einer zusätzlichen kommerziellen Lizenz. Die technische Entscheidung sollte mit Produktroadmap, Releaseplan und Supportpflichten abgestimmt werden.

Käufer sollten für jede offene Komponente Eigentümer, Aufwand, Abhängigkeiten, Frist und Nachweis festhalten. Ein Risiko, das erst nach Closing bereinigt werden kann, braucht eine klare Übergabepflicht und darf nicht durch eine unbestimmte Zusicherung verdeckt werden. Der Due-Diligence-Lückencheck hilft, fehlende Unterlagen und Verantwortlichkeiten zu strukturieren.

Der Garantiekatalog sollte nicht nur allgemein die Rechte am Quellcode bestätigen. Sinnvoll sind konkrete Aussagen zum Inventar, zu bekannten Lizenzverstößen, zu offenen Notice- oder Quellcodepflichten, zu Abmahnungen und zu Änderungen zwischen Signing und Closing. Offenlegungen gehören in eine nachvollziehbare Disclosure-Liste mit Bezug zur betroffenen Komponente.

Für identifizierte Risiken kommen je nach Befund eine Bereinigung als Closing-Bedingung, ein Kaufpreiseinbehalt, eine spezifische Freistellung, ein Escrow oder eine Nachbesserungspflicht in Betracht. Der allgemeine SPA-Garantiekatalog und die Vollzugsbedingungen müssen dabei mit dem technischen Maßnahmenplan übereinstimmen.