Open-Source-Lizenzen in Auftragssoftware: Was MIT, Apache und GPL für dein Projekt bedeuten

Auch eine Individualsoftware, die für dich geschrieben wird, besteht zu einem erheblichen Teil aus fremden Bausteinen. Der Entwicklungspartner setzt Programmbibliotheken, Frameworks und Werkzeuge ein, die unter Open-Source-Lizenzen stehen. Das ist üblich und sinnvoll. Es hat aber rechtliche Folgen für dich als Auftraggeber, weil jede dieser Lizenzen Bedingungen enthält. Der Artikel Wem gehört der Code? klärt, wie die Rechte an dem Code geregelt werden, den dein Dienstleister selbst schreibt. Hier geht es um den fremden Code darin.

Zwei Lizenzfamilien: permissiv und Copyleft

Open-Source-Lizenzen lassen sich grob in zwei Gruppen einteilen.

Permissive Lizenzen wie MIT, BSD und Apache 2.0 erlauben es, den Code zu nutzen, zu ändern und in eigene, auch geschlossene Produkte einzubauen. Die Bedingungen sind überschaubar: Lizenztext und Urheberhinweis müssen erhalten bleiben. Die Apache-Lizenz 2.0 enthält zusätzlich eine ausdrückliche Patentlizenz und verlangt, dass Änderungen an Dateien kenntlich gemacht werden.

Copyleft-Lizenzen wie die GNU General Public License (GPL) knüpfen die Nutzung an eine Gegenleistung: Wer ein Werk weitergibt, das GPL-Code enthält oder davon abgeleitet ist, muss das gesamte Werk unter denselben Bedingungen anbieten, einschließlich Quellcode. Die LGPL ist abgeschwächt und betrifft vor allem Änderungen an der Bibliothek selbst. Die AGPL (GNU Affero General Public License) geht weiter: Sie knüpft die Pflicht, Nutzern den Quellcode anzubieten, auch an die Nutzung über ein Netzwerk. Wer also eine AGPL-Komponente verändert und als Webdienst bereitstellt, löst die Pflicht möglicherweise aus, obwohl die Software nie "ausgeliefert" wurde.

Welche Folgen das im Einzelfall hat, hängt von der konkreten Lizenzversion, der Art der Einbindung und der Weitergabe ab. Genau das ist Gegenstand juristischer Prüfung.

Warum das für dich als Auftraggeber relevant ist

Wenn Software in deinem Unternehmen intern läuft und nicht weitergegeben wird, spielen Copyleft-Pflichten, die an die Weitergabe anknüpfen, eine geringere Rolle. Das ändert sich in diesen Fällen:

Du bietest die Software Kunden als Produkt an oder lieferst sie an Dritte weiter.
Du stellst sie über das Netzwerk bereit und eine eingesetzte Komponente steht unter der AGPL.
Du planst einen Verkauf des Unternehmens oder eine Finanzierungsrunde. Dabei prüfen Käufer und Investoren, welche Lizenzen im Code stecken (Due Diligence). Eine unklare Lage kann die Verhandlung verzögern oder den Preis beeinflussen.

Außerdem betrifft das Thema deine Handlungsfreiheit: Wenn du später das Entwicklungsteam wechseln oder die Software weiterverkaufen willst, solltest du wissen, was du darfst. Der Artikel Software-Übergabe: was passiert, wenn dein Dienstleister geht? behandelt diese Frage aus Sicht des Anbieterwechsels.

Was du vom Entwicklungspartner verlangen solltest

Mit diesen Vertragsbausteinen schaffst du Transparenz:

Liste der eingesetzten Fremdkomponenten. Eine sogenannte Software Bill of Materials (SBOM) führt jede Komponente mit Version und Lizenz auf. Moderne Build-Werkzeuge können sie automatisch erzeugen.
Lizenzen offenlegen vor dem Einsatz kritischer Komponenten. Vereinbare, dass der Dienstleister dich informiert, bevor er Komponenten unter Copyleft-Lizenzen (GPL, AGPL) einsetzt, und deine Zustimmung einholt.
Zusicherung zur Lizenzkonformität. Der Dienstleister sichert zu, dass er die Lizenzbedingungen der eingesetzten Komponenten einhält, insbesondere Hinweis- und Namensnennungspflichten.
Lizenzdokumentation als Liefergegenstand. Die SBOM und die Lizenztexte gehören zur Übergabe, zusammen mit der technischen Dokumentation.
Aktualisierung bei Weiterentwicklung. Vereinbare, dass die Liste bei jeder wesentlichen Änderung der Abhängigkeiten aktualisiert wird.

Typische Prüfpunkte in der Praxis

Wenn du eine vorhandene Lieferung prüfen lässt oder einen Anbieter fragst, kannst du diese Punkte anstoßen:

Gibt es eine automatisch erzeugte Liste aller Abhängigkeiten, auch der indirekten?
Wurden Komponenten ohne erkennbare Lizenz eingesetzt? Ohne Lizenz hast du grundsätzlich kein Nutzungsrecht.
Wie geht der Dienstleister mit Komponenten um, die doppelt lizenziert sind (zum Beispiel kommerziell oder unter der GPL)?
Wo stehen die erforderlichen Lizenzhinweise, etwa in einer "Open-Source-Hinweise"-Seite der Anwendung?

Sicherheit und Lizenz gehören zusammen

Die Liste der Fremdkomponenten hilft auch bei der IT-Sicherheit. Wird in einer Bibliothek eine Sicherheitslücke bekannt, kannst du anhand der Liste prüfen, ob deine Software betroffen ist. Der Artikel IT-Sicherheit im Pflichtenheft beschreibt, wie du Anforderungen dazu verankerst.

Fazit

Open-Source-Komponenten sind in Auftragssoftware ein Normalfall. Permissive Lizenzen wie MIT und Apache 2.0 verlangen vor allem die Erhaltung von Hinweisen. Copyleft-Lizenzen wie GPL und AGPL können Pflichten zur Offenlegung auslösen, abhängig von Einbindung und Weitergabe. Lass dir die Fremdkomponenten mit Lizenzen als Liste liefern, vereinbare Zustimmungspflichten für Copyleft und lass strittige Fälle juristisch prüfen.

Häufig gestellte Fragen

Muss ich meinen Quellcode veröffentlichen, wenn Open Source darin steckt?

Nicht automatisch. Bei permissiven Lizenzen besteht keine solche Pflicht. Bei Copyleft-Lizenzen kommt es auf Lizenz, Art der Einbindung und Weitergabe an. Die Frage lässt sich für den Einzelfall nur anhand der konkreten Komponenten beantworten.

Was ist eine SBOM?

Eine Software Bill of Materials ist eine Stückliste der Software. Sie enthält alle eingesetzten Komponenten mit Version und Lizenz. Sie hilft bei Lizenzprüfung und Sicherheitsfragen.

Darf mein Dienstleister Open Source ohne meine Zustimmung einsetzen?

Das regelt der Vertrag. Ohne Vereinbarung entscheidet der Dienstleister über die Technik. Wenn dir bestimmte Lizenzen wichtig sind, schreibe eine Zustimmungspflicht oder eine Ausschlussliste in den Vertrag.