Open-Source-Lizenzen: was GPL, MIT und Apache bei kommerzieller Nutzung verlangen

Betriebssysteme, Datenbanken, Webserver und Programmbibliotheken stehen zu einem großen Teil unter Open-Source-Lizenzen; wer Software entwickelt, einkauft oder als Dienst betreibt, verwendet solche Komponenten in nahezu jedem Produkt. Die Lizenzen gestatten die Nutzung unentgeltlich und auch zu Erwerbszwecken; eine Lizenz, die den Einsatz in einem Unternehmen oder einer Branche ausschließt, ist nach Punkt 6 der Open Source Definition keine Open-Source-Lizenz. Die Lizenzen knüpfen ihre Bedingungen an die Weitergabe der Software, auch in bearbeiteter Form; die AGPLv3 und die EUPL knüpfen sie zusätzlich an den Betrieb als Dienst.

Die Lizenz ist eine Erlaubnis nach dem Urheberrechtsgesetz

Computerprogramme sind Werke im Sinn des Urheberrechtsgesetzes, wenn sie das Ergebnis der eigenen geistigen Schöpfung ihres Urhebers sind (§ 40a Abs 1 UrhG). Der Urheber kann anderen die Benutzung gestatten (Werknutzungsbewilligung) oder ein ausschließliches Recht einräumen (Werknutzungsrecht, § 24 Abs 1 UrhG). Eine Open-Source-Lizenz ist nach unserer Einschätzung eine Werknutzungsbewilligung, die der Rechteinhaber jedermann unter Bedingungen anbietet. Die Bedingungen begrenzen die Erlaubnis: GPLv2 § 4 und GPLv3 § 8 erklären jede Vervielfältigung, Bearbeitung oder Weitergabe außerhalb der Lizenz für unwirksam und beenden die Rechte des Nutzers automatisch. Veröffentlichte Rechtssätze des OGH zu Open-Source-Lizenzen gibt es, soweit ersichtlich, nicht; die Einordnung beruht auf dem Gesetzeswortlaut und den Lizenztexten.

Die Lizenzgruppen und ihre Pflichten bei der Weitergabe

Die gängigen Lizenzen unterscheiden sich darin, was bei der Weitergabe geschuldet ist und ob eigener Code unter dieselbe Lizenz fällt.

• Permissive Lizenzen (MIT, BSD, Apache 2.0): Urheberrechtsvermerk und Lizenztext müssen jeder Kopie beiliegen. Die Apache License 2.0 verlangt bei der Weitergabe eine Kopie der Lizenz, Hinweise in geänderten Dateien, alle Rechtsvermerke und die Datei NOTICE (§ 4). Eigener Code darf unter beliebigen Bedingungen weitergegeben werden.
• Schwaches Copyleft (LGPL, MPL 2.0): Änderungen an der Komponente bleiben unter der Lizenz; eigener Code daneben fällt nicht darunter. Die MPL 2.0 knüpft an die Datei an: Der Quellcode der Covered Software muss verfügbar sein; ein Larger Work mit anderem Code darf unter Bedingungen eigener Wahl stehen (Ziffer 1.10, 3.2 und 3.3). Die LGPLv3 erlaubt dasselbe für ein Combined Work, wenn Lizenz und Hinweis beiliegen und der Empfänger die Bibliothek austauschen kann, etwa durch dynamisches Linken (§ 4).
• Starkes Copyleft (GPLv2, GPLv3): Wer das Programm verändert und weitergibt, muss das Werk als Ganzes unter der GPL lizenzieren (GPLv2 § 2 lit b, GPLv3 § 5 lit c). Zur Weitergabe in Objektcode gehört der vollständige Quellcode, beigefügt oder durch ein schriftliches Angebot für mindestens drei Jahre zugesagt (GPLv2 § 3, GPLv3 § 6). Ein Entgelt für die Kopie ist erlaubt (GPLv3 § 4); die bloße Zusammenstellung unabhängiger Programme bringt diese nicht unter die GPL (GPLv2 § 2, GPLv3 § 5).
• Netzwerk-Copyleft (AGPLv3): Wer das Programm verändert und Nutzern über ein Netz zugänglich macht, muss diesen Nutzern den Quellcode der geänderten Fassung anbieten (§ 13). Bei der GPL ist der Netzbetrieb ohne Übergabe einer Kopie kein „convey" und löst keine Pflicht aus (GPLv3 § 0).
• EUPL 1.2: Die Lizenz der Europäischen Kommission verlangt Hinweise, Lizenztext, Quellcode und die Weitergabe unter der EUPL (Art 5); zur Verbreitung zählt auch der Zugang zu den wesentlichen Funktionen, also der Betrieb als Dienst (Art 1). Verbindungen von EUPL-Code mit Code unter GPL, AGPL, LGPL oder MPL 2.0 dürfen unter dieser anderen Lizenz weitergegeben werden (Art 5 und Anhang).

Die Business Source License und die Server Side Public License zeigen den Quellcode, beschränken aber den produktiven Einsatz oder den Betrieb als Dienst. Die Llama-Lizenz stellt Modell und Code zur Verfügung, schränkt aber Nutzung und Nutzerkreis ein. Keine der drei ist eine Open-Source-Lizenz, wie die Business Source License über sich sagt und die Open Source Initiative für die SSPL und die Llama-Lizenz festgehalten hat. Offen verfügbare KI-Modelle stehen häufig unter solchen Bedingungen; sie behandeln wir in einem eigenen Beitrag.

Wann die Pflichten entstehen

Interner Einsatz. Wer Open-Source-Software nur im eigenen Unternehmen einsetzt und verändert, hat keine Pflichten aus der Lizenz (GPLv3 § 2, GPLv2 §§ 0 und 2). Eine Tochter- oder Schwestergesellschaft ist eine eigene Rechtsperson; die Weitergabe im Konzern ist nach dem Wortlaut der GPLv3 ein „convey" an „other parties" (§ 0). Ausgenommen ist die Weitergabe an einen Auftragnehmer, auch eine Konzerngesellschaft, der die Software ausschließlich für den Auftraggeber bearbeitet oder betreibt (GPLv3 § 2).

Verkauf eines Produkts oder Geräts. Mit der Auslieferung an Kunden sind alle Weitergabepflichten zu erfüllen: Lizenztexte, Hinweise, bei Copyleft der Quellcode oder das schriftliche Angebot. Bei einem körperlichen Produkt gilt das Angebot nach GPLv3 § 6 lit b mindestens drei Jahre und so lange, wie Ersatzteile oder Kundendienst für das Modell angeboten werden. Bei Geräten für Verbraucher kommen die Installationsinformationen für geänderte Fassungen dazu, es sei denn, niemand kann geänderte Software auf dem Gerät installieren (§ 6).

Bibliotheken verbinden. Soweit ersichtlich hat kein österreichisches Gericht in einem veröffentlichten Rechtssatz entschieden, ob ein Programm, das eine GPL-Bibliothek nur aufruft oder dynamisch mit ihr verbunden wird, ein Werk „based on the Program" ist. Die LGPLv2.1 geht davon aus, dass ein durch Linken entstandenes Programm ein abgeleitetes Werk der Bibliothek ist (§ 5). Wer eigenen Code nicht unter die GPL stellen will, wählt eine Bibliothek unter LGPL, MPL oder einer permissiven Lizenz.

Auftragsentwicklung. Liefert ein Dienstleister oder ein freier Entwickler Code mit Open-Source-Komponenten, treffen die Weitergabepflichten den Auftraggeber, sobald er das Produkt vertreibt. Der Vertrag muss deshalb die Komponenten mit ihren Lizenzen auflisten und zusichern, dass keine Lizenz der vorgesehenen Nutzung entgegensteht. Für Programme, die Dienstnehmer in Erfüllung ihrer dienstlichen Pflichten schaffen, steht das Werknutzungsrecht dem Dienstgeber zu, wenn nichts anderes vereinbart ist (§ 40b UrhG); bei freien Entwicklern muss der Vertrag die Rechte einräumen.

Was ein Verstoß auslöst

Wer die Bedingungen nicht einhält, handelt ohne Werknutzungsbewilligung. Jeder Rechteinhaber kann auf Unterlassung klagen, bei Gemeinschaftsprojekten jeder Miturheber für sich (§ 11 Abs 2 UrhG); der Inhaber eines Unternehmens haftet auf Unterlassung auch für Verletzungen, die seine Bediensteten oder Beauftragten im Betrieb des Unternehmens begehen (§ 81 Abs 1 UrhG). Dazu kommen der Beseitigungsanspruch bis zur Vernichtung der rechtswidrig hergestellten Vervielfältigungsstücke (§ 82 UrhG), ein angemessenes Entgelt ohne Rücksicht auf ein Verschulden (§ 86 Abs 1 UrhG) und bei Verschulden Schadenersatz einschließlich des entgangenen Gewinns, nach Wahl des Verletzten das Doppelte des angemessenen Entgelts oder die Herausgabe des erzielten Gewinns (§ 87 Abs 1, 3 und 4 UrhG).

Nach GPLv2 § 4 endet die Lizenz mit dem Verstoß; eine Heilung sieht der Text nicht vor. Eine neue Lizenz kann nur der Rechteinhaber einräumen. Die GPLv3 stellt die Rechte vorläufig wieder her, sobald der Verstoß beendet ist, und endgültig, wenn der Rechteinhaber die Verletzung nicht binnen 60 Tagen nach der Beendigung anzeigt; zeigt ein Rechteinhaber die Verletzung zum ersten Mal an, werden die Rechte endgültig wiederhergestellt, wenn der Verstoß binnen 30 Tagen nach Zugang behoben wird (§ 8). Die Lizenzen der Empfänger, die vom Verletzer Kopien erhalten haben, bleiben bestehen, nach GPLv2 nur, solange diese Empfänger die Lizenz einhalten (GPLv2 § 4, GPLv3 § 8).

Gewährleistung und Haftung

Alle genannten Lizenzen schließen Gewährleistung und Haftung aus, soweit das anwendbare Recht es zulässt (GPLv3 §§ 15 bis 17, Apache §§ 7 und 8, MIT, BSD, MPL 2.0 Ziffer 6 und 7, EUPL Art 7 und 8); die EUPL nimmt Vorsatz, Schäden an natürlichen Personen und die gesetzliche Produkthaftung aus (Art 8). Wie weit diese Ausschlüsse nach österreichischem Recht wirken, ist durch veröffentlichte Rechtsprechung nicht geklärt. Gegenüber Verbrauchern ist ein Ausschluss der Haftung für Personenschäden sowie für Vorsatz und grobe Fahrlässigkeit jedenfalls unwirksam (§ 6 Abs 1 Z 9 KSchG); zwischen Unternehmern unterliegt ein Ausschluss in vorformulierten Bedingungen der Kontrolle auf gröbliche Benachteiligung (§ 879 Abs 3 ABGB).

Der Ausschluss wirkt nur zwischen dem Open-Source-Urheber und seinem Lizenznehmer. Gegenüber dem eigenen Kunden haftet das Unternehmen, das die Software in sein Produkt einbaut, nach Vertrag und Gewährleistungsrecht, als hätte es den Code selbst geschrieben. Die Lizenzen lassen zu, Gewährleistung oder Haftung gegen Entgelt zu übernehmen (GPLv3 § 4, Apache § 9, MPL 2.0 Ziffer 3.5); wer das nach Apache oder MPL tut, handelt im eigenen Namen und muss die Urheber von Ansprüchen freihalten.

Produkthaftung und Cyber Resilience Act

Die Produkthaftungsrichtlinie (EU) 2024/2853 behandelt Software als Produkt; sie gilt nicht für freie und quelloffene Software, die außerhalb einer Geschäftstätigkeit entwickelt oder bereitgestellt wird (Art 2 Abs 2). Wer solche Software im Rahmen seiner Geschäftstätigkeit in ein Produkt einbaut, haftet dafür wie für jede andere Komponente (Erwägungsgrund 15). Einzelheiten enthält der Beitrag zur Produkthaftung für Software ab Dezember 2026.

Der Cyber Resilience Act (Verordnung (EU) 2024/2847) erfasst Produkte mit digitalen Elementen, die im Rahmen einer Geschäftstätigkeit bereitgestellt werden; unentgeltliche quelloffene Software ohne Monetarisierung fällt nicht darunter (Erwägungsgrund 18). Hersteller müssen bei der Integration von Komponenten Dritter, auch quelloffener, die gebotene Sorgfalt walten lassen (Art 13 Abs 5); eine Schwachstelle in einer Komponente melden sie deren Hersteller oder Betreuer und beheben sie (Art 13 Abs 6). Zur Behandlung von Schwachstellen gehört eine maschinenlesbare Software-Stückliste, die zumindest die obersten Abhängigkeiten des Produkts ausweist (Anhang I Teil II Nr 1). Die Verordnung gilt ab dem 11. Dezember 2027; die Meldepflichten des Art 14 für aktiv ausgenutzte Schwachstellen gelten seit dem 11. September 2026 (Art 71 Abs 2).

Was Unternehmen jetzt einrichten

• Inventar führen: Jede Komponente wird mit Version, Lizenz und Herkunft erfasst, auch die mittelbaren Abhängigkeiten; für Produkte mit digitalen Elementen wird das Inventar zur Software-Stückliste.
• Lizenz vor der Weitergabe prüfen: Vor jeder Auslieferung, Veröffentlichung und jedem Dienststart ist zu klären, welche Lizenz welche Pflicht auslöst.
• Pflichten erfüllen: Lizenztexte, Urheberrechtsvermerke und NOTICE-Dateien liegen dem Produkt bei; für Copyleft-Komponenten besteht ein schriftliches Quellcodeangebot, das mindestens drei Jahre gilt.
• Verträge mit Entwicklern und Lieferanten: Der Vertrag enthält die Liste der Komponenten, die Zusicherung lizenzkonformer Auswahl und die Rechteeinräumung am eigenen Code.
• Unternehmenskauf: Die Lizenzprüfung gehört in die Due Diligence. Nach GPLv3 § 10 erhält der Erwerber eines Unternehmens oder seines Vermögens die Lizenzen des Vorgängers und einen Anspruch auf den Quellcode; hat der Verkäufer seine Lizenz durch einen Verstoß verloren, erhält auch der Erwerber keine (§ 8).

Bei der Lizenzprüfung vor einer Produkteinführung, bei Verträgen mit Entwicklern und bei der Due Diligence unterstützen wir Sie im IT-Recht.

Diese Information ist allgemein gehalten und ersetzt keine Beratung im Einzelfall.