Softwarelizenzen verstehen: Eine Einführung mit Schwerpunkt Open Source

Kaum ein Softwareprojekt kommt heute ohne fremde Komponenten aus: Frameworks, Bibliotheken, Betriebssystemteile, Container-Images. Ein großer Teil davon steht unter Open-Source-Lizenzen. Wer Software entwickelt, weiterverkauft oder für Kunden anpasst, sollte die wichtigsten Lizenztypen und ihre Pflichten kennen, denn ein Lizenzverstoß passiert häufig nicht aus Absicht, sondern aus Unwissenheit. Ein Überblick für den Einstieg.

Was ist eine Softwarelizenz überhaupt?

Software ist urheberrechtlich geschützt. Wer sie nutzen, vervielfältigen, verändern oder weitergeben will, braucht dafür grundsätzlich die Erlaubnis des Rechteinhabers, soweit nicht ausnahmsweise das Gesetz die Nutzung gestattet. Die Lizenz ist die Einräumung dieser Nutzungsrechte. Sie legt fest, was erlaubt ist (etwa Nutzung, Änderung, Weitergabe), unter welchen Bedingungen und mit welchen Einschränkungen.

Es gibt also keine „lizenzfreie" Software. Auch Open-Source-Software ist urheberrechtlich geschützt, der Rechteinhaber räumt die Nutzungsrechte aber großzügig und im Voraus gegenüber jedermann ein, allerdings unter Bedingungen, die man einhalten muss.

Proprietäre Software und Open Source im Vergleich

Proprietäre Software wird vom Hersteller meist ohne Quellcode und mit eng begrenzten Nutzungsrechten bereitgestellt. Was erlaubt ist, ergibt sich aus dem Lizenzvertrag oder den Nutzungsbedingungen, häufig mit Beschränkungen bei Weitergabe, Änderung oder Anzahl der Nutzer.

Open-Source-Software zeichnet sich dagegen dadurch aus, dass der Quellcode zugänglich ist und die Lizenz bestimmte Freiheiten garantiert: die Software frei zu nutzen, zu untersuchen, zu verändern und weiterzugeben. Als Orientierung dient in der Praxis die Open Source Definition der Open Source Initiative. Wichtig: „Open Source" bedeutet nicht „kostenlos" und nicht „ohne Bedingungen". Die Bedingungen unterscheiden sich allerdings je nach Lizenz erheblich.

Die wichtigsten Lizenzfamilien

Open-Source-Lizenzen lassen sich grob in drei Gruppen einteilen. Entscheidend ist die Frage, welche Pflichten bestehen, wenn man die Software weitergibt oder in ein eigenes Produkt einbaut.

1. Permissive Lizenzen (z. B. MIT, BSD, Apache 2.0) Diese Lizenzen stellen nur geringe Anforderungen. In der Regel muss der Lizenztext samt Urhebervermerk beibehalten werden. Die Software darf aber auch in proprietäre, kommerzielle Produkte eingebaut werden, ohne dass der eigene Quellcode offengelegt werden muss. Die Apache-2.0-Lizenz enthält zusätzlich eine ausdrückliche Patentlizenz und einige weitere Hinweispflichten.

2. Schwaches Copyleft (z. B. LGPL, MPL) Copyleft bedeutet, dass bestimmte Pflichten an Weiterentwicklungen „vererbt" werden. Bei schwachem Copyleft gilt das nur eingeschränkt: Änderungen an der Bibliothek selbst (bei der MPL: an den jeweils lizenzierten Dateien) müssen unter derselben Lizenz offengelegt werden, während eigener Code, der die Bibliothek lediglich nutzt, grundsätzlich eigenen Bedingungen unterliegen kann. Die genauen Voraussetzungen, etwa bei der LGPL zum Austausch der Bibliothek durch den Nutzer, sollten im Einzelfall geprüft werden.

3. Starkes Copyleft (z. B. GPL, AGPL) Hier gilt: Wer ein Werk weitergibt, das auf GPL-Software beruht oder sie in einer Weise einbindet, die ein einheitliches „abgeleitetes Werk" begründet, muss das Gesamtwerk grundsätzlich ebenfalls unter der GPL bereitstellen und den Quellcode zugänglich machen. Die AGPL geht noch einen Schritt weiter: Auch wer die Software nur als Dienst über ein Netzwerk anbietet (etwa als Webanwendung), kann zur Offenlegung des Quellcodes gegenüber den Nutzern verpflichtet sein.

Sonderfall EUPL Die European Union Public Licence (EUPL) wurde von der EU-Kommission entwickelt, ist ein Copyleft-Modell mit einer Kompatibilitätsregelung zu anderen Lizenzen und wird im öffentlichen Sektor häufiger genutzt. Sie liegt in mehreren Sprachfassungen vor.

Typische Fallstricke in der Praxis

1. Die „Ansteckung" durch Copyleft wird unterschätzt Besonders bei GPL und AGPL ist entscheidend, wie eine Komponente in das eigene Produkt eingebunden wird (statisches oder dynamisches Linken, separater Prozess, Plugin-Architektur). Die rechtliche Bewertung, ob ein abgeleitetes Werk vorliegt, ist im Einzelfall komplex und wird nicht einheitlich beurteilt.

Praxistipp: Vor dem Einbau von Copyleft-Komponenten in kommerzielle Produkte die Einbindungsart dokumentieren und im Zweifel rechtlich bewerten lassen.

2. Lizenzkompatibilität Nicht jede Lizenz lässt sich mit jeder anderen kombinieren. Werden Komponenten unter unterschiedlichen Lizenzen in einem Produkt zusammengeführt, können sich die Bedingungen widersprechen. Typisch ist etwa die Kombination von Komponenten, die jeweils unterschiedliche Copyleft-Bedingungen stellen.

Praxistipp: Eine Übersicht der verwendeten Lizenzen führen und bei neuen Komponenten vorab prüfen, ob sie mit dem Bestand kompatibel sind.

3. Abhängigkeiten werden nicht überblickt Moderne Software besteht oft aus Dutzenden oder Hunderten Abhängigkeiten, die ihrerseits weitere Abhängigkeiten einbinden. Lizenzen dieser „transitiven" Abhängigkeiten gelten ebenfalls. Wer nur die direkt eingebundenen Bibliotheken kennt, übersieht schnell Pflichten.

Praxistipp: Eine Stückliste der Softwarebestandteile (Software Bill of Materials, SBOM) führen oder mit gängigen Werkzeugen zur Lizenzerkennung arbeiten. Das hilft auch gegenüber Kunden und Auftraggebern, die zunehmend danach fragen.

4. Hinweis- und Namensnennungspflichten werden vergessen Auch permissive Lizenzen verlangen in der Regel, dass Lizenztext und Urhebervermerke in der Dokumentation oder im Produkt enthalten sind. Das wird häufig nicht umgesetzt, weil es keinen Programmierfehler darstellt, sondern eine Dokumentationsaufgabe ist.

Praxistipp: Eine feste Stelle im Produkt oder in der Dokumentation für Drittlizenzen („Third-Party Notices") einrichten und bei Releases aktualisieren.

5. Rechtsfolgen eines Lizenzverstoßes Wer die Lizenzbedingungen nicht einhält, riskiert, dass die eingeräumten Nutzungsrechte entfallen. Es drohen Unterlassungsansprüche, Auskunfts- und Schadensersatzansprüche sowie Abmahnungen. In der Praxis haben Rechteinhaber und Organisationen, die Lizenzverstöße verfolgen, in der Vergangenheit entsprechende Ansprüche geltend gemacht. Einige Lizenzen, etwa neuere Versionen der GPL, sehen unter Umständen eine Möglichkeit zur Heilung innerhalb bestimmter Fristen vor.

Praxistipp: Bei einem erkannten Verstoß frühzeitig reagieren: Compliance herstellen, Dokumentation ergänzen und, wenn nötig, den Kontakt zu Rechteinhabern suchen, bevor es zur Eskalation kommt.

6. Gewährleistung und Haftung bei Open Source Open-Source-Lizenzen schließen die Gewährleistung und Haftung des Urhebers regelmäßig weitgehend aus. Wer Open-Source-Komponenten in ein Produkt einbaut, das er seinen Kunden entgeltlich liefert, trägt gegenüber dem Kunden aber grundsätzlich die eigene Verantwortung für das Gesamtprodukt. Der Haftungsausschluss des Urhebers hilft im Verhältnis zum eigenen Kunden nur begrenzt.

Praxistipp: Vertragliche Zusagen an Kunden zu Gewährleistung und Support so formulieren, dass sie zu den tatsächlich eingebauten Open-Source-Komponenten passen, und klären, wer Sicherheitsupdates für diese Komponenten übernimmt.

Open Source im öffentlichen Sektor

Für Anbieter, die an öffentliche Auftraggeber liefern, spielt Open Source aus mehreren Gründen eine Rolle: Öffentliche Stellen legen zunehmend Wert auf offene Standards, Interoperabilität und die Vermeidung von Anbieterabhängigkeit. Das kann dazu führen, dass in Ausschreibungen offene Schnittstellen, die Nutzung von Open-Source-Komponenten oder die Bereitstellung entwickelter Software unter einer Open-Source-Lizenz gefordert oder bewertet werden. Gleichzeitig verlangen manche Auftraggeber Auskunft über verwendete Drittkomponenten und deren Lizenzen.

Wer hier belastbare Angaben machen kann, hat einen Vorteil. Fehlende Übersicht über die eigenen Open-Source-Bestandteile kann dagegen im Verfahren zum Problem werden, etwa wenn Nutzungsrechte an entwickelter Software eingeräumt werden sollen, aber unklar ist, welche Teile überhaupt frei vergeben werden dürfen.

Fazit

Open-Source-Software ist kein rechtsfreier Raum, sondern urheberrechtlich geschützt und an Lizenzbedingungen gebunden, deren Pflichten sich je nach Lizenztyp stark unterscheiden. Permissive Lizenzen sind unkompliziert, Copyleft-Lizenzen verlangen genaues Hinsehen, und eine saubere Übersicht über alle verwendeten Komponenten ist die wichtigste Grundlage für rechtssichere Entwicklung und für belastbare Aussagen gegenüber Kunden und Auftraggebern. Wer das früh organisiert, spart sich spätere Auseinandersetzungen.

Sie haben Fragen zu einem konkreten Lizenzvertrag?