Open Source in der Softwareentwicklung: Rechtliche Grundlagen und Praxis

Open-Source-Software ist aus der modernen Softwareentwicklung – ob bei der Entwicklung von Computerspielen (Game Development) oder bei Plugins für populäre Plattformen wie WordPress oder Shopify – nicht mehr wegzudenken. Entwickler greifen aus Kostengründen und aufgrund der großen Community-Unterstützung gerne auf frei verfügbare Bibliotheken, Engines und Codeschnipsel zurück. Doch „frei verfügbar“ bedeutet nicht „frei von Bedingungen“. Gerade im IT-Recht und Medienrecht spielen die rechtlichen Rahmenbedingungen solcher Open-Source-Lizenzen eine zentrale Rolle. Insbesondere das Urheberrecht und das Vertragsrecht setzen den Einsatz von Open Source bestimmte Grenzen, die Entwickler und Unternehmen kennen müssen.

Dieser Blogpost gibt einen umfassenden Überblick über den Einsatz von Open Source im Game Development und in der Plugin-Entwicklung. Der Fokus liegt auf praktischen Aspekten: Lizenzkompatibilität zwischen gängigen Lizenzen (wie GPL, MIT, Apache), Risiken und Rechtsfolgen bei Lizenzverstößen, Auswirkungen von Copyleft-Lizenzen (insbesondere der GPL) auf proprietäre Software, sowie vertragliche Punkte wie Integrationsklauseln, Prüfpflichten und Due Diligence. Die Darstellung erfolgt neutral und juristisch präzise, aber zugleich verständlich für die Praxis. Entwickler von Spielen, Software und Plugins sollen erkennen, worauf sie achten müssen, um rechtliche Fallstricke zu vermeiden. Begriffe aus dem IT-Recht, Urheberrecht und Vertragsrecht werden erläutert, relevante deutsche Rechtsnormen – etwa aus dem Urheberrechtsgesetz (UrhG) – sowie Gerichtsentscheidungen und Beispiele aus der Praxis werden einbezogen.

Grundlagen der Open-Source-Lizenzen

Open Source und Urheberrecht

Open Source Software (OSS) bezeichnet Software, deren Quellcode öffentlich zugänglich ist und von Dritten genutzt, verändert und weiterverbreitet werden darf – jedoch unter bestimmten Lizenzbedingungen. Juristisch basiert dieses Modell auf dem Urheberrecht: Nach deutschem Recht genießt Software als sogenanntes Computerprogramm den Schutz des Urheberrechts (§ 2 Abs. 1 Nr. 1, § 69a UrhG). Der Urheber (oder Rechteinhaber) einer Software verfügt über umfassende ausschließliche Nutzungsrechte (§ 69c UrhG), u.a. das Recht, das Programm zu vervielfältigen, zu verbreiten, zu verändern oder öffentlich zugänglich zu machen. Ohne Zustimmung des Rechteinhabers darf niemand die Software rechtmäßig kopieren oder verbreiten.

Eine Softwarelizenz ist genau diese Zustimmung: In einem Lizenzvertrag räumt der Urheber einem Nutzer bestimmte Nutzungsrechte ein (§ 31 UrhG). Open-Source-Lizenzen sind in der Regel vorformulierte Standardlizenzen, in denen die Urheber jedermann bestimmte Rechte an der Software einräumen – typischerweise kostenlos und zeitlich unbeschränkt – jedoch gekoppelt an Bedingungen. Diese Bedingungen unterscheiden Open-Source-Lizenzen von rein „freier“ (bedingungsloser) Public-Domain-Software. Rechtlich betrachtet haben Open-Source-Lizenzen oft den Charakter Allgemeiner Geschäftsbedingungen (AGB), da sie vom Urheber einseitig gestellt und bei Nutzung der Software akzeptiert werden. Daher müssen sie mit dem AGB-Recht (§§ 305 ff. BGB) im Einklang stehen.

Wichtig ist: Auch wenn keine Vertragsunterschrift geleistet wird, gilt die Open-Source-Lizenz durch konkludente Handlung – wer die Software verwendet oder verbreitet, erklärt sich mit den Lizenzbedingungen einverstanden. Bei Open Source findet der „Vertragsschluss“ gewissermaßen durch Nutzung der Software statt. Die OSI (Open Source Initiative) definiert Kriterien, wann eine Lizenz als „Open Source“ gilt (freie Weiterverbreitung, Einsicht in den Quellcode, Erlaubnis zu Änderungen, keine Diskriminierung von Personen oder Einsatzbereichen etc.). Bekannte Beispiele sind die GNU General Public License (GPL), die MIT-Lizenz, die Apache License 2.0, die BSD-Lizenzen und viele mehr.

Permissive vs. Copyleft-Lizenzen

Open-Source-Lizenzen lassen sich grob in zwei Kategorien einteilen: permissive Lizenzen und Copyleft-Lizenzen. Der Unterschied liegt in der Stärke der Auflagen, die an die Weiternutzung des Codes geknüpft werden.

Permissive Lizenzen (deutsch: freizügige Lizenzen) gewähren umfangreiche Rechte und stellen nur minimale Bedingungen. Beispiele sind die MIT-Lizenz, die Apache License 2.0 oder die BSD-Lizenzen. Sie erlauben es, die Software nahezu ohne Einschränkungen in eigene Projekte zu integrieren, sogar in proprietäre Software, und weiterzuverbreiten. Typischerweise verlangen sie nur, dass ein Urheberrechtsvermerk (Copyright Notice) und der Lizenztext bzw. ein Lizenzhinweis in der Software beibehalten werden. So schreibt etwa die MIT-Lizenz vor, dass bei weiterverbreitetem Code der ursprüngliche Lizenztext mitgeführt wird. Die Apache License 2.0 enthält zusätzlich eine ausdrückliche Erteilung von Patentlizenzen an Nutzer der Software und einige Schutzklauseln (z.B. bei Änderung der Namen/Marken), bleibt aber ebenfalls „permissiv“ in dem Sinne, dass abgeleitete Werke unter beliebiger Lizenz (auch proprietär) veröffentlicht werden dürfen, solange die wenigen Auflagen erfüllt werden. Permissive Lizenzen sind bei Entwicklern beliebt, weil sie maximale Freiheit bieten und kaum rechtliche Konflikte verursachen – man kann aus permissiv lizenziertem Code eigene geschlossene Software bauen, ohne später Quellcode offenlegen oder andere Nutzungspflichten erfüllen zu müssen.

Copyleft-Lizenzen hingegen stellen stärkere Bedingungen und zielen darauf ab, die Freiheit des Codes weiterzuvererben. „Copyleft“ bedeutet vereinfacht gesagt, dass abgeleitete Werke des lizenzierten Codes wiederum unter der gleichen Lizenz veröffentlicht werden müssen. Die Idee dahinter ist der Schutz der Offenheit: Niemand soll den freien Code nehmen und daraus einen proprietären, für andere unzugänglichen Ableger machen können, ohne die eigenen Änderungen ebenfalls der Gemeinschaft bereitzustellen. Die GNU General Public License (GPL) ist die bekannteste und strengste Copyleft-Lizenz. Sie erlaubt den Nutzern zwar, das Programm kostenlos zu verwenden, zu ändern und weiterzuverbreiten, knüpft dies aber an Bedingungen: Beim Weitervertrieb muss der Quellcode der abgeleiteten Software offengelegt werden, und es muss wiederum die GPL-Lizenz darauf angewendet werden. Zusätzlich fordert die GPL, dass ein Hinweis auf den Lizenzgeber (Copyright-Vermerk) erhalten bleibt und dass eine Kopie der Lizenz dem Programm beigefügt wird. Auch ein Haftungsausschluss und Gewährleistungsausschluss ist Bestandteil der GPL – wobei in Deutschland aus AGB-rechtlichen Gründen ein vollständiger Haftungsausschluss für Vorsatz und grobe Fahrlässigkeit unwirksam wäre (§ 309 Nr. 7 BGB). Wesentlicher Kern der GPL ist: Wenn ich ein GPL-lizenziertes Programm oder Bibliothek in meine eigene Software integriere und diese dann verbreite, muss meine gesamte Software unter der GPL stehen und der Quellcode offen zugänglich sein.

Neben der „starken“ GPL gibt es abgeschwächte Copyleft-Lizenzen. Die LGPL (Lesser GPL) beispielsweise gilt als „schwaches Copyleft“: Sie erlaubt, dass eine LGPL-Bibliothek in proprietäre Software eingebunden wird, solange die Bibliothek an sich weiterhin austauschbar und unter LGPL bleibt. Praktisch bedeutet das oft dynamisches Linken einer DLL oder .so-Datei; die proprietäre Software muss dann die Möglichkeit bieten, vom Endnutzer die Bibliothek gegen eine andere Version auszutauschen. Die eigene Software muss nicht GPL/LGPL sein, aber Änderungen an der LGPL-Komponente selbst müssten wiederum veröffentlicht werden. Eine weitere Variante ist die AGPL (Affero GPL), die eine Lücke der GPL schließt: Bei AGPL-lizenzierter Software muss auch dann der Quellcode offengelegt werden, wenn die Software nicht klassisch verbreitet, sondern über ein Netzwerk als Service genutzt wird (Stichwort Software-as-a-Service). Sie ist relevant, wenn jemand z.B. einen AGPL-lizenzierten Server oder Webdienst modifiziert und der Öffentlichkeit anbietet – dann entsteht ebenfalls die Pflicht, den Quellcode der Änderungen bereitzustellen.

Zusammenfassend: Permissive Lizenzen (MIT, Apache, BSD etc.) sind unkompliziert und vereinbar mit proprietärer Nutzung, da sie kaum Einschränkungen außer Urhebernennung kennen. Copyleft-Lizenzen (GPL und ähnliche) sichern die Offenheit und zwingen Weiterentwickler zur Reziprozität: Wer nimmt, muss auch wieder geben. Beide Modelle sind in der Praxis verbreitet; welches zum Einsatz kommt, hängt von den Zielen des Urhebers ab. Für Game Developer und Plugin-Entwickler ist wichtig zu erkennen, unter welche Kategorie eine verwendete Komponente fällt, da dies später darüber entscheidet, ob und wie man die eigene Software veröffentlichen darf.

Typische Open-Source-Lizenzen im Überblick

An dieser Stelle lohnt ein kurzer Blick auf die wichtigsten Einzellizenzen, die in der Praxis von Spiele- und Plugin-Entwicklung häufig angetroffen werden:

• GNU General Public License (GPL): Aktuell v.a. Version 3 (GPLv3) sowie noch viele Projekte unter Version 2 (GPLv2). Striktes Copyleft. Bedingungen: Weitergabe des Quellcodes der ganzen abgeleiteten Software, gleicher Lizenztyp für die Weitergabe, Einbindung des GPL-Lizenztexts, Nennung der Urheber. Oft verwendet für Endanwendungen und auch Bibliotheken, wo Durchsetzung von Offenheit gewünscht ist (z.B. viele Linux-Programme, aber auch einige Spiel-Engines, die als Open Source freigegeben wurden). Beispiel: Die id Tech 3 Engine (Basis von Quake 3) wurde unter GPL freigegeben – wer darauf aufbauend ein Spiel veröffentlicht, müsste dessen Code ebenfalls unter GPL stellen.

• MIT-Lizenz (Expat): Sehr kurze und einfache Lizenz. Jeder darf alles mit dem Code tun (ändern, verkaufen, lizenzieren), Haftung wird ausgeschlossen, Bedingung: der MIT-Lizenztext und Copyright-Hinweis müssen in allen Kopien oder signifikanter Teilen davon erhalten bleiben. Keine Copyleft-Vorgaben – d.h. man kann MIT-Code in proprietäre Projekte übernehmen. Beispiel: Die JavaScript-Bibliothek jQuery ist MIT-lizenziert; sie kann in kommerziellen Web-Projekten genutzt werden, solange irgendwo im Impressum oder Code der Lizenzhinweis steht.

• Apache License 2.0: Umfangreicher als MIT, aber ebenfalls permissiv. Zusätzlich zu den MIT-Pflichten schreibt sie vor, dass bei Distribution von geänderter Software kenntlich gemacht wird, was geändert wurde, und sie enthält eine Patentlizenz: Beitragsleistende Urheber gewähren dem Nutzer Patentrechte, die zur Nutzung des Codes nötig sind. Umgekehrt gibt es eine Klausel, dass man diese Patentlizenz verliert, falls man wegen Patentverletzung gegen den Anbieter klagt (Vermeidung von Patentstreitigkeiten). Trotz dieser Zusätze ist Apache 2.0 im Kern frei: Abgeleitete Software darf auch anders lizenziert sein (proprietär), wieder mit der Maßgabe, den Apache-Lizenztext beizulegen und Urhebervermerke zu wahren. Beispiel: Das Framework TensorFlow von Google steht unter Apache 2.0 – Unternehmen können es intern oder kommerziell nutzen, ohne ihren eigenen Code offenlegen zu müssen.

• BSD-Lizenzen: Hier gibt es die „3-Klausel-BSD“ (oder „New BSD“) und ähnliche. Sie ähneln der MIT-Lizenz: Erlauben nahezu alles, fordern lediglich Erhalt von Urheberhinweisen. Eine ältere Variante, die 4-Klausel-BSD, enthielt eine Werbeklausel (Urheber musste in Werbematerial genannt werden), die aber als zu restriktiv galt und inkompatibel zur GPL war. Moderne BSD-Lizenzen sind GPL-kompatibel (dazu im nächsten Abschnitt mehr) und weit verbreitet, z.B. im Networking-Bereich oder bei Betriebssystemen (FreeBSD etc.).

• Mozilla Public License 2.0 (MPL): Ein Mittelweg zwischen Copyleft und Permissiv. MPL ist dateibasiertes Copyleft: Änderungen an MPL-lizenzierten Dateien müssen bei Weitergabe offengelegt werden, aber man darf diese Dateien in ein größeres Projekt einbinden, ohne dass das gesamte Projekt offen sein muss. Proprietäre und MPL-Dateien können nebeneinander existieren (solange getrennte Dateien). Diese Lizenz wird hier nur am Rande erwähnt, da GPL, MIT und Apache die häufigeren Fälle in unserem Fokus (Game Dev, Plugins) sind. Allerdings nutzt z.B. Mozilla seine MPL für Firefox, und auch einige Bibliotheken im Softwarebereich sind MPL-lizenziert. Für Plugin-Entwickler ist MPL selten relevant, häufiger sieht man GPL oder MIT.

Fazit der Grundlagen: Die verschiedenen Lizenztypen legen fest, unter welchen Bedingungen Code verwendet werden darf. Entwickler sollten frühzeitig klären, welche Lizenz ein Open-Source-Baustein hat und was das konkret bedeutet – muss ich bei Verwendung meinen eigenen Code ebenfalls frei lizenzieren (Copyleft) oder reicht ein einfacher Hinweis (permissiv)? Diese Frage ist der Dreh- und Angelpunkt für die weitere Nutzung in eigenen (möglicherweise kommerziellen) Projekten.

Lizenzkompatibilität in der Praxis

Wenn in einem Softwareprojekt mehrere Komponenten mit unterschiedlichen Lizenzen zusammenkommen, stellt sich das Problem der Lizenzkompatibilität. Darunter versteht man, ob zwei (oder mehr) Lizenzbedingungen miteinander vereinbar sind, sodass man den betreffenden Code gemeinsam verwenden und vertreiben darf, ohne gegen eine der Lizenzen zu verstoßen.

Was bedeutet Lizenzkompatibilität?

Jede Open-Source-Lizenz setzt gewisse Pflichten voraus. Wenn ich Software A unter Lizenz X habe und Software B unter Lizenz Y, und ich will A und B in einem Projekt kombinieren (z.B. eine Bibliothek A einbinden in Programm B), dann müssen die Lizenzbedingungen zueinander passen. Inkompatibel sind Lizenzen, wenn die eine Bedingungen hat, die sich mit denen der anderen widersprechen oder die Erfüllung beider gleichzeitig unmöglich machen. Kompatibel sind sie, wenn ich durch einen bestimmten Lizenzierungsweg beiden gerecht werden kann.

Ein Beispiel: Code unter MIT-Lizenz und Code unter GPL-Lizenz kann zusammen in einem Projekt verwendet werden – allerdings nur unter der Maßgabe, dass das Gesamtprodukt dann unter die GPL gestellt wird, sobald es verteilt wird. Warum? Die MIT-Lizenz erlaubt Weiterverbreitung unter beliebigen Bedingungen (solange Urheberhinweis bleibt); sie ist damit GPL-kompatibel, weil sie keine Klauseln enthält, die der GPL widersprechen. Ich kann also MIT-Code in ein GPL-Projekt übernehmen, muss dann aber das Endergebnis unter GPL lizenzieren (denn die GPL verlangt das für das Gesamtwerk). Andersherum, GPL-Code in ein MIT-lizenziertes Projekt zu stecken und dieses weiter unter MIT zu veröffentlichen, ginge nicht, weil dann die Pflichten der GPL verletzt würden (GPL fordert, dass Gesamtwerk GPL ist, MIT würde das nicht abdecken). In so einem Fall muss praktisch alles unter GPL laufen.

GPL und permissive Lizenzen

Die GPL ist bekannt dafür, wählerisch bei ihren „Partnern“ zu sein: Sie verträgt sich mit vielen permissiven Lizenzen, aber längst nicht mit allen. GPL-kompatibel sind z.B.:

• MIT-Lizenz und 2- oder 3-Klausel-BSD-Lizenzen – diese haben keine Bedingungen, die der GPL zuwiderlaufen. Der Code kann übernommen werden; die resultierende Software darf (bzw. muss sogar) unter GPL stehen. Der ursprüngliche MIT/BSD-Code wird in dem Moment faktisch ebenfalls unter GPL mitvertrieben, aber das ist erlaubt, weil die ursprüngliche Lizenz es zulässt.

• Apache License 2.0 und GPL: Hier ist der Teufel im Detail der Versionen. Apache 2.0 wurde von der Free Software Foundation als inkompatibel mit GPLv2 eingestuft. Der Grund: Apache 2.0 enthält eine Klausel über Patentlizenz und Beendigung derselben bei Patentklagen. GPLv2 hat keine entsprechende Klausel und enthält die strikte Vorgabe, dass beim Weiterverteilen keine zusätzlichen Restriktionen auferlegt werden dürfen. Eine Patentbeendigungsklausel könnte aber als zusätzliche Restriktion angesehen werden. Daher gilt: Apache 2.0 + GPLv2 = konfliktträchtig. Folglich darf man keinen Code unter Apache 2.0 in ein reines GPLv2-Projekt integrieren, ohne gegen eine der Lizenzen zu verstoßen. Allerdings ist Apache 2.0 kompatibel mit GPLv3. Die GPL Version 3 wurde nämlich so gestaltet, dass deren eigene Regelungen zu Patenten mit der Apache-Lizenz harmonieren. Somit kann man Code unter Apache 2.0 und Code unter GPLv3 zusammenbringen, indem man das Gesamtwerk unter GPLv3 veröffentlicht (GPLv3 erlaubt ausdrücklich Apache-Code zu integrieren, solange Hinweis und Apache-spezifische Anforderungen erfüllt werden).

• Weitere Beispiele: MPL 2.0-Code kann in GPLv3-Projekten genutzt werden, da MPL 2.0 eine Klausel hat, die Kompatibilität mit GPLv3 erlaubt (der MPL-Code kann dual unter GPL gestellt werden bei Bedarf). Solche Sonderregeln gibt es für einige Lizenzen, spielen aber im typischen Game Dev weniger eine Rolle.

Generell gilt: Permissive → Copyleft ist meist möglich (d.h. permissiver Code kann in ein copyleft-Projekt einfließen, das Ergebnis wird eben copyleft). Copyleft → permissiv ist problematisch, da das copyleft Material seine Bedingungen „mitbringt“, die in einer rein permissiven (oder gar proprietären) Veröffentlichung nicht erfüllt würden.

Inkompatible Kombinationen

Lizenzinkompatibilität kann auf mehreren Weisen auftreten:

• Widersprüchliche Bedingungen: Zwei Lizenzen fordern Unvereinbares. Beispiel: Ein hypothetischer Fall wäre eine Lizenz, die verlangt „es darf kein Urhebervermerk in der Software genannt werden“ kombiniert mit einer, die verlangt „Urhebervermerk muss genannt werden“. Sowas wäre direkt widersprüchlich. In realen OSS-Lizenzen kommt das selten so krass vor, da alle seriösen Lizenzen Nennung des Urhebers erlauben. Aber subtilere Fälle gibt es, z.B. die alte GPLv2 vs Apache 2.0-Problematik wie oben genannt.

• Copyleft vs Copyleft: Zwei verschiedene Copyleft-Lizenzen können inkompatibel sein. Beispiel: Code unter GPLv2 (ohne „oder höher“-Klausel) und Code unter GPLv3. Diese beiden Versionen der GPL sind untereinander inkompatibel, da GPLv3 zusätzliche Bedingungen hat, die GPLv2-Nutzer nicht akzeptiert haben. Daher können Projekte, die unter GPLv2-only stehen, keinen GPLv3-Code einbinden und umgekehrt, ohne dual zu lizenzieren. In der Praxis werden viele GPLv2-Projekte mit „GPLv2 oder später“ lizenziert, um diese Hürde abzubauen. Ein anderes Beispiel: GPL (Copyleft) und LGPL (schwächeres Copyleft) – hier ist die Kopplung in der Regel so, dass LGPL-Code in GPL-Code überführt werden kann (GPL höherer Stufe schlägt quasi durch), aber nicht umgekehrt ohne Verletzung der GPL.

• Proprietär vs Copyleft: Das ist die häufigste relevante Inkompatibilität. Proprietäre (nicht-offene) Software hat per se die „Lizenz“ des Herstellers, der meist alle Rechte vorbehalten hat. Kopiert man nun ungefragt GPL-Code hinein, entsteht ein abgeleitetes Werk, das den GPL-Bedingungen unterliegt. Wenn der Hersteller aber nicht bereit ist, den gesamten Code unter GPL zu stellen, gerät er in einen Widerspruch: Er verteilt faktisch GPL-pflichtigen Code unter einer proprietären Lizenz – ein klarer Lizenzverstoß. Diese Kombination ist nicht erlaubt, solange man die Bedingungen nicht erfüllt. Es sei denn, der proprietäre Hersteller holt sich eine separate Erlaubnis vom GPL-Code-Urheber (z.B. durch einen dualen Lizenzvertrag). Ein praktisches Beispiel war der Fall VMware vs. GPL-Community: VMware baute Teile des Linux-Kernels (GPL) in ein proprietäres Produkt ein. Ohne Sonderlizenz ist das inkompatibel – was letztlich zum Rechtsstreit (Hellwig ./. VMware) führte, den wir später noch beleuchten.

Kurz gesagt: Vor Einbau einer Open-Source-Komponente sollte immer geprüft werden, ob deren Lizenz mit der Gesamtlizenz des Projekts vereinbar ist. Lizenzkompatibilitätstabelle: Viele Organisationen stellen Übersichten bereit, welche Lizenzen als mit GPL kompatibel gelten. Die Free Software Foundation z.B. listet auf, dass MIT, BSD, zlib etc. alle GPL-kompatibel sind, während etwa die frühere Apple Public Source License nicht kompatibel war. Für die tägliche Arbeit eines Entwicklers genügt oft folgende Daumenregel: Verwende möglichst permissive Lizenzen, dann hast Du kaum Kompatibilitätsprobleme. Wenn Du bereits GPL im Projekt hast, achte darauf, dass zusätzlich genutzter Code zumindest GPL-kompatibel ist (oder ebenfalls GPL). Wenn Du proprietär bleiben willst, vermeide GPL-Code, da dieser Dich zwingen würde, die Proprietarität aufzugeben.

Kumulierung von Lizenzpflichten

Lizenzkompatibilität heißt nicht, dass man sich aussuchen kann, welche Lizenz gilt – in einem Kombinationsprodukt muss man alle anwendbaren Lizenzpflichten erfüllen. Oft wird das Endprodukt unter einer einzelnen Lizenz angeboten (z.B. alles unter GPL, wenn quelloffen; oder das eigene proprietäre EULA, wenn geschlossen). Dennoch muss man dabei gleichzeitig sicherstellen, dass die Bedingungen der integrierten Open-Source-Komponenten eingehalten sind. In der Praxis bedeutet das z.B.:

• Notices sammeln: Jedes Stück eingebundener OSS erfordert, dass man den entsprechenden Lizenztext und Urhebervermerk weitergibt. Entwickler sollten daher eine Dokumentation aller Third-Party-Komponenten führen. Oft findet man im Installationsverzeichnis kommerzieller Software Dateien wie NOTICE.txt oder OpenSourceLicenses.txt, in denen alle verwendeten OSS-Bestandteile mit Lizenz aufgeführt sind. Das ist eine Umsetzung der kumulierten Lizenzanforderungen.

• Quellcode anbieten: Wenn auch nur eine Komponente im Produkt unter GPL steht und das Produkt verteilt wird, muss der Anbieter dem Lizenznehmer den kompletten entsprechenden Quellcode zur Verfügung stellen (GPLv2) bzw. ein schriftliches Angebot dazu machen (GPLv3), unabhängig davon, wie klein die Komponente ist. Es reicht nicht, nur den Code dieser einen Komponente bereitzustellen – da das gesamte Werk als abgeleitet gilt, fällt darunter auch eigener Code, der mit der Komponente verbunden wurde. Ausnahme: Dynamisch gelinkte LGPL-Bibliotheken – hier muss man „nur“ ermöglichen, dass der Nutzer die LGPL-Komponente austauschen kann, was praktisch erfordert, die eigenen Objektfiles zu liefern oder dynamisches Linken zu unterstützen.

• Namensnennung: Einige Lizenzen (z.B. CC0 für Code, oder auch früher die 4-clause-BSD) fordern, dass man den Namen des Autors in Werbematerial nennt. Solche exotischeren Pflichten sollte man kennen, falls man entsprechende Lizenzen einsetzt, damit man sie nicht übersieht. Im Bereich klassischer Softwarelizenzen kommen solche Forderungen selten vor (bei CC-Lizenzen im Medienbereich eher).

Ein typisches Beispiel einer kumulierten Pflicht in einem kommerziellen Produkt: Ein Computerspiel nutzt 5 Open-Source-Bibliotheken – eine unter MIT, eine unter Apache, zwei unter BSD, eine unter zlib. Alle sind permissiv, also muss das Spielteam keinen eigenen Code offenlegen. Aber jede dieser Lizenzen verlangt, dass ihr Lizenztext irgendwo im Paket vorhanden ist. Das Spielstudio fügt also im Spielordner eine LICENSES-Datei ein, in der die Texte aller fünf Lizenzen + Copyright der jeweiligen Entwickler stehen. Damit sind die Lizenzbedingungen erfüllt, und das proprietäre Spiel kann legal mit diesen Komponenten vertrieben werden.

WordPress-Plugins und Lizenzkompatibilität

Ein Spezialfall, den viele Plugin-Entwickler kennen, ist das Thema WordPress-Plugins und -Themes. WordPress selbst steht unter GPLv2. Die Macher von WordPress (Automattic) vertreten die Auffassung, dass jedes Plugin und jedes Theme, das WordPress verwendet oder darauf aufbaut, als derivativer Ableitung von WordPress anzusehen ist. Somit muss nach dieser Auffassung jedes Plugin ebenfalls GPL-kompatibel lizenziert sein – im Idealfall ebenfalls unter GPL. Tatsächlich verlangen die offiziellen Verzeichnisse (das WordPress Plugin Repository) und Marktplätze, dass hochgeladene Erweiterungen unter GPLv2 (oder einer kompatiblen Lizenz) stehen. Inkompatible Lizenzen (etwa rein proprietäre EULAs oder bestimmte eingeschränkte Lizenzen) führen dazu, dass das Plugin dort nicht aufgenommen wird.

Rechtlich ist die Frage, ob ein Plugin ein abgeleitetes Werk der Hauptsoftware ist, nicht abschließend geklärt – es gibt Argumente, dass die Verwendung definierter Plugin-Schnittstellen (Hooks, APIs) allein noch keine Bearbeitung im Sinne des Urheberrechts darstellt, sondern eine erlaubte Ankopplung. Allerdings sind die Grenzen fließend: Sobald ein Plugin WordPress-Code direkt kopiert oder in den Speicher lädt (was faktisch immer passiert, da es Funktionen der WordPress-Core-Bibliotheken aufruft), kann man sehr wohl von einer Bearbeitung oder zumindest einer abhängigen Verbindung sprechen. Vorsichtige Entwickler halten sich daher an die GPL, um keinen Konflikt mit WordPress’ Lizenz einzugehen. Es hat zwar – soweit bekannt – in Deutschland noch keine Gerichtsklage von WordPress-Urhebern gegen einen Plugin-Entwickler wegen Lizenzverstoßes gegeben, doch die Community-Regeln sorgen de facto für Durchsetzung: Wer nicht GPL-konform lizenziert, wird von den wichtigen Distributionskanälen ausgeschlossen und riskiert einen Image-Schaden.

Ein interessanter Praxisfall war ein Rechtsstreit um ein WordPress-Theme vor dem OLG Karlsruhe (Urteil vom 27.01.2021, Az. 6 U 60/20). Dort hatte ein Entwickler ein kommerzielles Theme auf Basis von WordPress erstellen lassen und vertrieben, ohne den Quellcode offenzulegen. Ein Dritter (vermutlich ein Konkurrent oder ein Open-Source-Aktivist) verlangte dann die Offenlegung des Theme-Codes unter Berufung auf die GPL. Das OLG Karlsruhe stellte klar, dass aus der GPL zwar folgt, dass der Entwickler bei Verbreitung eigentlich den Code offenlegen müsste – aber wenn er es nicht tut, bedeutet das nicht, dass nun ein anderer das Recht hätte, diesen Code einfach zu veröffentlichen. Der exklusive Rechteinhaber des Themes (der Entwickler) hat durch einen GPL-Verstoß nicht automatisch sein Urheberrecht an den eigenen Anteilen verloren. Anders formuliert: Die GPL schafft keine allgemeinen Nutzungsrechte für jedermann an der abgeleiteten Software, solange der Entwickler nicht selbst die Lizenzbedingungen erfüllt. Die Konsequenz eines Verstoßes ist vielmehr, dass niemand das Werk rechtmäßig verbreiten darf – weder der Verletzer selbst noch Dritte. Dieses Urteil betraf zwar die Frage der Rechtewahrnehmung (der Theme-Entwickler konnte einem Dritten verbieten, sein Theme auf GitHub zu stellen, obwohl es GPL-pflichtig wäre), aber es zeigt indirekt auch die Lizenzkompatibilitätsthematik: WordPress und ein nicht-GPL-Theme sind eigentlich inkompatibel in dem Sinne, dass das Theme nicht hätte proprietär vertrieben werden dürfen. Nur: einklagen kann das primär der WordPress-Rechteinhaber; Dritte können das nicht eigenmächtig durchsetzen.

Fazit zur Kompatibilität

Gerade bei größeren Projekten im Game Development kommen oft Dutzende fremder Komponenten zusammen – z.B. eine Physik-Engine, Audio-Bibliotheken, Netzwerk-Libraries etc. – möglicherweise mit unterschiedlichen Lizenzen. Es ist unerlässlich, vor der Integration zu prüfen, ob alle Lizenzen zueinander und zum geplanten Endprodukt passen. Im Zweifel sollte man zu einer Komponente mit strenger Lizenz eine Alternative mit einer kompatibleren Lizenz suchen. Zahlreiche Tools und Übersichten stehen zur Verfügung, um diese Fragen zu klären. Lizenzkompatibilität ist damit ein ebenso technisches wie rechtliches Thema: technisch müssen die Komponenten harmonieren, rechtlich ihre Lizenzen. Nur wenn beides stimmt, kann man das Projekt sorgenfrei veröffentlichen.

Auswirkungen von Copyleft-Lizenzen auf proprietäre Software

Ein zentrales Anliegen dieses Artikels ist die Frage nach den Auswirkungen von Copyleft (insbesondere GPL) auf proprietäre Software. Damit ist gemeint: Was passiert, wenn ein Entwickler oder Unternehmen, das eigentlich sein eigenes Programm nicht offenlegen will (etwa ein kommerzielles Spiel oder eine geschlossene Software), dennoch Open-Source-Code unter einer Copyleft-Lizenz einsetzt? Welche Pflichten entstehen und wie weit reichen sie?

„Viraler“ Effekt der GPL

Oft ist in diesem Zusammenhang vom „viral effect“ die Rede. Gemeint ist das Szenario: Eine Komponente unter GPL wird in ein größeres Softwareprodukt eingebunden. Nach den GPL-Bedingungen „infiziert“ die Lizenz das Gesamtprodukt dahingehend, dass es insgesamt nur unter GPL weitergegeben werden darf. Wie ein Virus, der alle Zellen befällt, breitet sich die Lizenzbedingung auf das Gesamtkunstwerk aus. Konsequenz: Das zuvor proprietäre Projekt müsste – sofern man es weiterhin verteilen will – seinen Quellcode offenlegen und ebenfalls unter GPL stellen. Aus Sicht des Unternehmens bedeutet das eine potentielle Preisgabe von Geschäftsgeheimnissen und Verlust der Exklusivität an der Software.

In rechtlicher Terminologie spricht man davon, dass die GPL eine auflösende Bedingung enthält: Die eingeräumten Nutzungsrechte stehen unter der Bedingung, dass man bei Verbreitung der Software die Lizenzauflagen erfüllt. Tritt ein Lizenzverstoß ein (etwa weil man die eigenen Quelltexte nicht preisgibt), erlischt die Lizenz automatisch (so z.B. ausdrücklich Ziffer 4 GPLv2, bzw. Ziffer 8 GPLv3). Dadurch fehlt die Berechtigung, das Werk weiter zu verbreiten – es liegt eine Urheberrechtsverletzung vor, sofern man es dennoch tut. Der Entwickler gerät also in eine Lose-Lose-Situation: Entweder er erfüllt die Bedingungen (d.h. veröffentlicht seinen Code offen – was er nicht wollte), oder er muss auf die Distribution verzichten (d.h. das Feature/den Code entfernen oder das Produkt zurückhalten). Diese Zwangslage ist das, was man mit „viral“ beschreibt.

Aus Sicht der Copyleft-Befürworter ist das kein unfairer Trick, sondern bewusst so gewollt: Wer freie Software nutzt, soll zur Gemeinschaft beitragen. Aus Unternehmenssicht dagegen wirkt es „ansteckend“ und riskant, weshalb viele Firmen penibel darauf achten, keine GPL- oder ähnlich lizenzierte Komponente in ihre proprietären Produkte geraten zu lassen.

Umfang der Ansteckung: Was gilt als abgeleitetes Werk?

Eine entscheidende Frage ist, wie weit der Copyleft-Effekt reicht. Nicht immer ist klar, ob eine Software A, die mit B interagiert, wirklich als „Bearbeitung“ oder abgeleitetes Werk von B gilt. Das Urheberrecht (insb. § 23 UrhG) definiert, dass Bearbeitungen eines Werkes nur mit Zustimmung des Urhebers veröffentlicht werden dürfen. Die GPL erteilt diese Zustimmung unter Bedingungen. Aber wenn ich argumentieren kann, dass meine Software gar keine Bearbeitung des GPL-Werks ist, dann greift die Pflicht nicht.

In der Praxis werden einige Abgrenzungen diskutiert:

• Statisches vs. dynamisches Linking: Wenn ich eine GPL-Bibliothek statisch in mein Programm einbinde (d.h. der Code wird beim Kompilieren zu einer Einheit verschmolzen), ist es eindeutig ein abgeleitetes Werk. Bei dynamischem Linking (die Bibliothek bleibt separat als .dll oder .so und wird zur Laufzeit geladen) ist die Lage etwas komplexer. Die Free Software Foundation vertritt die Ansicht, dass auch dynamisch gelinkte Module Teil eines abgeleiteten Werks sind, weil sie gemeinsam im Speicher laufen und miteinander kommunizieren. Einige Juristen und Entwickler meinen hingegen, dynamisches Linken sei eher eine Schnittstellen-Nutzung, vergleichbar mit zwei unabhängigen Programmen, die zusammenarbeiten – insbesondere wenn die Bibliothek unverändert bleibt und nur über definierte API-Aufrufe verwendet wird. In EU/Deutschlands Urheberrecht gibt es das Konzept der „freien Benutzung“ (§ 24 a.F. UrhG, für Software in der EU allerdings enger) und der nicht schutzfähigen Schnittstellen (EuGH-Entscheidung SAS Institute vs World Programming, 2012, hat festgelegt, dass Funktionalität und Schnittstellen keine Urheberrechte genießen). Diese könnten argumentativ herangezogen werden, um zu sagen: Das eigene Programm nutzt nur die Funktionalität der Bibliothek über eine definierte Schnittstelle, ohne eine unzulässige Bearbeitung vorzunehmen. Allerdings ist das riskantes Terrain – es gibt keine höchstrichterliche Entscheidung, die generell sagt „dynamisches Linking fällt nicht unter GPL-Copyleft“. Die meisten Experten raten daher: Verlasse dich nicht darauf, dass dynamic linking dich aus der Copyleft-Pflicht rettet, zumal viele GPL-Projekte explizit klarstellen, dass auch Plugins/Module als Bearbeitung gelten.

• Inter-Prozess-Kommunikation: Wenn zwei Programme getrennt laufen und etwa über eine Pipeline, Netzwerk oder Datei Schnittstelle Daten austauschen, gelten sie in der Regel als eigenständige Werke. Beispiel: Ein proprietäres Programm ruft ein GPL-Kommandozeilenprogramm auf und liest dessen Ausgabe. Hier findet keine Vermischung auf Code-Ebene statt; es sind zwei Prozesse. Nach verbreiteter Auffassung erzeugt dies keinen Copyleft-Effekt auf das aufrufende Programm – es bleibt eigenständig lizenziert. Allerdings muss das GPL-Programm natürlich für sich betrachtet lizenzkonform weitergegeben werden (also Quellcode etc.). Solche Architekturen (Trennung in einen GPL-Teil und einen proprietären Teil über definierte Schnittstelle) werden manchmal bewusst gewählt, um Open Source nutzen zu können, ohne die eigene Codebasis öffnen zu müssen. Dieses „Workaround“ ist legal zulässig, solange die Grenze der Werke gewahrt bleibt. Aber Achtung: Es darf nicht offensichtlich nur ein Kunstgriff sein, um Copyleft zu umgehen, wo eigentlich eine starke Verbindung bestünde.

• Plugins und der Plattform-Effekt: Wie bei WordPress diskutiert, stellt sich bei Plugins immer die Frage, ob das Plugin ein abgeleitetes Werk der Plattform ist oder die Plattform ein abgeleitetes Werk des Plugins – in beide Richtungen. Die GPL propagiert, dass jede Verbindung in ein gemeinsames Werk resultiert, sofern nicht eine klare Trennlinie (z.B. via IPC) vorliegt. Somit können GPL-Plattformen (wie WordPress, WooCommerce etc.) bewirken, dass Plugins sich unter GPL-Lizenz stellen müssen. Umgekehrt, proprietäre Plattformen (wie Shopify oder Adobe Photoshop etc.) zwingen eigene Lizenzbedingungen auf, aber dort hat der Plugin-Entwickler meist freie Hand, solange er die Plattform-EULA nicht verletzt – er wird aber durch GPL-Komponenten im Plugin vorsichtig sein, um nicht sein eigenes Plugin offenlegen zu müssen. Mehr dazu im Abschnitt über Plugins.

Beispiele aus dem Game Development

Im Game Development gibt es einige bekannte Fälle und Best Practices im Umgang mit Copyleft:

• Spiel-Engines: Einige populäre Open-Source-Spiel-Engines stehen unter GPL. Ein Beispiel war die id Tech 4 Engine (Basis von Doom 3), die id Software nach einigen Jahren unter GPL veröffentlichte. Damit konnten zwar Community und andere Entwickler darauf aufbauen, aber kommerziell hat danach kaum jemand diese Engine verwendet, denn es hätte bedeutet, den Code des gesamten Spiels offenzulegen. Stattdessen greifen kommerzielle Studios lieber auf Engines zurück, die permissiv lizenziert sind (z.B. Godot Engine unter MIT-Lizenz) oder auf kommerzielle Engines mit eigenen Lizenzen (Unity, Unreal Engine unter proprietären/kommerziellen Lizenzen). Diese bieten zwar nicht den Quellcode frei an (oder nur gegen NDA), haben dafür aber klare kommerzielle Nutzungsrechte ohne Copyleft. Das zeigt: Der starke Copyleft-Effekt der GPL schreckt Unternehmen im Game-Bereich oft ab, wenn die Geschäftsstrategie Closed Source vorsieht.

• Libraries in Spielen: Viele Spiele nutzen Drittanbieter-Bibliotheken für bestimmte Funktionen (Physik, KI, UI-Frameworks). Fast immer achten die Entwickler darauf, dass diese Libraries permissiv sind (MIT, BSD, zlib etc.) oder zumindest LGPL (wo nur Änderungen an der Lib offengelegt werden müssten). GPL-lizenzierte Libraries versucht man zu meiden. Ein historisches Beispiel: Die OGG Vorbis Audio-Bibliothek für Spiele war ursprünglich BSD-lizenziert (also problemlos), während die Alternativ-Bibliothek FAAC (für AAC-Audio) lange unter GPL stand, weshalb kommerzielle Projekte sie nicht anfassten. Viele Audio-Codecs wurden daher entweder selbst entwickelt oder lizenziert, statt GPL-Code zu nutzen.

• Mods und Tools: Interessant ist, dass manche Spiele, die selbst proprietär sind, Modding-Tools oder Skriptschnittstellen unter GPL oder LGPL mitliefern, weil das Spiel selbst davon entkoppelt bleibt. Zum Beispiel könnte ein Entwickler ein Level-Editor-Tool unter GPL bereitstellen, das der Community hilft, neue Inhalte zu erstellen – das hat keinen Einfluss auf die Lizenz des eigentlichen Spiels, solange das Tool separat ist.

• Dual Licensing: Einige Firmen veröffentlichen Teile ihrer Software unter GPL, um die Open-Source-Community zu bedienen, bieten aber gleichzeitig proprietäre Lizenzen für zahlende Kunden an. Dieses Modell (Dual Licensing) nutzt das Copyleft als Hebel: Wer die Software in Closed-Source-Projekten nutzen will, darf die GPL-Pflichten abkaufen. MySQL AB hat das z.B. lange so gehandhabt (GPL für Community, proprietäre Lizenz für Kunden). Im Game Dev ist das seltener, aber es gibt Tools (z.B. gewisse Middleware), die eine ähnliche Strategie fahren.

Strategien im Umgang mit Copyleft

Wenn man als Entwickler vor der Entscheidung steht, eine nützliche Komponente zu verwenden, die aber unter GPL steht, gibt es einige Strategien:

• Alternative suchen: Oft gibt es funktional ähnliche Bibliotheken mit liberaler Lizenz. Die Suche mag Zeit kosten, zahlt sich aber aus, um spätere Konflikte zu vermeiden.

• Isolieren: Lässt sich eine GPL-Komponente nicht ersetzen (weil sie etwas Einzigartiges leistet), könnte man versuchen, sie so einzubinden, dass kein abgeleitetes Werk entsteht. Etwa indem sie in einem separaten Prozess läuft und mit dem Hauptprogramm über definierte Protokolle kommuniziert. So bleibt die Hauptsoftware proprietär, während die GPL-Komponente als eigenständiges Tool mitgeliefert wird (inklusive Quellcode, um GPL zu erfüllen). Beispiel: Ein Level-Generator, der als eigenständiges CLI-Programm (GPL) mit dem Spiel gebündelt wird; das Spiel ruft nur extern „LevelGenerator.exe“ auf. Das geht allerdings nur für bestimmte Anwendungsfälle.

• Beitrag leisten und veröffentlichen: Manchmal entschließt sich ein Projekt bewusst, selbst Open Source zu werden, insbesondere bei Indie-Entwicklern. Dann kann man auch GPL-Code nutzen, ohne Widerspruch – man veröffentlicht eben das gesamte Spiel inkl. Source. Das mag kommerziell unattraktiv erscheinen, aber es gibt Fälle, wo durch offene Entwicklung und eventuell andere Einnahmemodelle (Spenden, Dienstleistungen) das funktioniert. Für Unternehmen, die klassisch Lizenzerlöse erzielen wollen, ist das jedoch selten eine Option.

• Lizenzberatung einholen: Im Zweifel sollte man einen Rechtsberater hinzuziehen. Es gibt Spezialisten im IT-Recht/Urheberrecht, die bei der Analyse helfen können: Ist ein bestimmter Integrationsweg zulässig, welche Pflichten entstünden genau, gibt es Klauseln, die man nutzen kann (z.B. wenn ein Lizenzgeber Sondergenehmigungen erteilt)? Auch klärt der Berater, ob vielleicht gar keine Urheberrechtsschutz besteht – zum Beispiel, wenn nur winzige Code-Schnipsel übernommen wurden, die nicht die Schöpfungshöhe erreichen. Allerdings ist das bei Software selten der Fall; praktisch jeder nicht trivial kopierte Code genießt Schutz.

Zusammengefasst: Copyleft-Lizenzen wie die GPL haben erhebliche Auswirkungen auf proprietäre Software, indem sie die Offenlegungspflicht auslösen. Entwickler sollten diese Wirkung verstehen und bei Design- und Technologie-Entscheidungen berücksichtigen. In großen Firmen gibt es dafür oft strikte Richtlinien (ein internes Lizenz-Blacklist/Whitelist-System). In kleinen Entwicklerteams liegt die Verantwortung beim Lead-Developer oder CTO, ein Auge auf die Lizenzen der verwendeten Tools zu haben. Wer den viralen Effekt unterschätzt, kann im Worst Case gezwungen sein, die eigene Software unter Bedingungen zu stellen, die der Geschäftsstrategie zuwiderlaufen.

Risiken und Rechtsfolgen bei Lizenzverstößen

Welche Konsequenzen drohen, wenn man die Bedingungen einer Open-Source-Lizenz nicht einhält? Dieser Abschnitt beleuchtet die rechtlichen Risiken – von Abmahnungen über Gerichtsverfahren bis zu möglichen Schadensersatzforderungen – und stützt sich dabei insbesondere auf deutsches Recht (UrhG) und einige bekannte Fälle.

Lizenzverstoß = Urheberrechtsverletzung

Zunächst muss man sich klar machen: Ein Open-Source-Lizenzverstoß ist kein Kavaliersdelikt, sondern rechtlich eine Urheberrechtsverletzung. Denn die Berechtigung, fremden Code zu nutzen, ergibt sich allein aus der Lizenz. Hält man die Lizenz nicht ein, existiert keine wirksame Nutzungsrechtseinräumung (§ 31 UrhG) – man verwendet den Code dann ohne Erlaubnis des Rechteinhabers. Das verletzt dessen ausschließliche Rechte (z.B. Vervielfältigungs- und Verbreitungsrecht gem. § 69c UrhG für Software).

In Deutschland hat sich hierzu eine klare Rechtsprechungslinie gebildet: Die GPL-Lizenz (als exemplarische Open-Source-Lizenz) wird als auflösend bedingt erteiltes Nutzungsrecht verstanden (vgl. LG Frankfurt a.M., Urteil vom 06.09.2006 – Az. 2-6 O 224/06). Das heißt, das Recht zur Nutzung und Verbreitung besteht nur so lange, wie man die Bedingungen (Quellcodeweitergabe, Hinweis etc.) erfüllt. Bei Verstoß entfällt das Recht automatisch. Dies ist AGB-rechtlich zulässig (nicht überraschend oder unzumutbar gemäß § 307 BGB, wie Gerichte festgestellt haben) und umgeht nicht § 31 UrhG, sondern nutzt dessen Rahmen.

Was also droht bei einem solchen Verstoß? Im Zivilrecht typischerweise:

• Unterlassungsanspruch (§ 97 Abs. 1 UrhG): Der Rechteinhaber kann verlangen, dass der Verletzer es künftig unterlässt, die Software in unzulässiger Weise zu nutzen oder zu verbreiten. Dieser Unterlassungsanspruch kann im Eilverfahren (einstweilige Verfügung) schnell durchgesetzt werden, wenn Eile geboten ist, oder im normalen Klageweg. In der Praxis wird in Deutschland meistens zuerst eine Abmahnung ausgesprochen: Das ist eine formale Aufforderung, den Verstoß abzustellen und eine strafbewehrte Unterlassungserklärung abzugeben. Für den Abgemahnten bedeutet das, er soll sich verpflichten, den Lizenzverstoß nicht zu wiederholen, anderenfalls zahlt er eine Vertragsstrafe. Damit können Prozesse oft vermieden werden. Gerade Gruppen wie gpl-violations.org (initiiert von Harald Welte) haben in der Vergangenheit zahlreiche Unternehmen abgemahnt, die z.B. Linux-Komponenten in ihren Geräten verwendeten, ohne die Quelltexte bereitzustellen. Viele dieser Fälle endeten nach Abmahnung mit einer außergerichtlichen Einigung: der Verletzer lieferte den Source-Code nach und übernahm die Abmahnkosten, um einen Prozess zu vermeiden.

• Beseitigung / Rückruf / Vernichtung: Neben der Unterlassung kann der Rechteinhaber fordern, dass vorhandene rechtswidrige Kopien beseitigt werden (§ 98 UrhG). Bei Software würde das bedeuten, die weitere Verbreitung zu stoppen, Produkte aus dem Verkehr zu ziehen, oder zumindest die fragliche Komponente aus dem Produkt zu entfernen. In der Praxis: Wenn ein Gerät mit verletzender Software ausgeliefert wurde, könnte verlangt werden, dass es nicht weiter verkauft wird, bis der Mangel behoben ist. Dies kann extreme Folgen haben – z.B. Verkaufsstopp eines Produkts oder Rückrufaktion.

• Auskunftsanspruch (§ 101 UrhG): Um Schadensersatz beziffern zu können, darf der Rechteinhaber Auskunft verlangen, in welchem Umfang die Verletzung stattfand (z.B. Stückzahl der verbreiteten Software, Umsätze damit etc.). Im Open-Source-Kontext ist das relevant, wenn später ein Schadensersatz beansprucht wird.

• Schadensersatz (§ 97 Abs. 2 UrhG): Wurde vorsätzlich oder fahrlässig gehandelt, schuldet der Verletzer Schadensersatz. In der Realität stellt sich aber die Frage, wie berechnet man einen Schaden bei Open-Source-Verstößen? Drei Methoden kennt das Urheberrecht grundsätzlich: (a) konkreter Vermögensschaden des Rechteinhabers; (b) Herausgabe des Verletzergewinns; (c) Lizenzanalogie (fiktive Lizenzgebühr). Variante (a) scheidet oft aus, weil Open-Source-Entwickler ihre Software ja nicht kommerziell verkaufen – ihr „Verlust“ durch einen Verstoß ist eher ideeller Natur oder betrifft die Gemeinschaft. Variante (b), Gewinnabschöpfung, könnte in krassen Fällen in Betracht kommen: Hat ein Unternehmen sehr viel Geld gespart oder verdient, weil es OSS unrechtmäßig nutzte, könnte man argumentieren, dieser Vorteil sei herauszugeben. Das ist aber komplex und selten praktiziert, da die Kausalität und Berechnung schwierig sind. Bleibt Variante (c), Lizenzanalogie: Man fragt, welche Gebühr vernünftige Parteien für die Nutzung vereinbart hätten. Nun ist OSS aber kostenlos lizenziert – gerade keine Lizenzgebühr. Einige Gerichte haben dennoch anfänglich eine Art „fiktive Lizenzgebühr“ angesetzt, quasi als Strafschätzung. So hatte das LG Bochum 2016 einem Kläger Schadensersatz zugesprochen, indem es einen Betrag X als angemessene Lizenzgebühr schätzte, obwohl die Lizenz eigentlich gratis war. In der Berufung hat das OLG Hamm (Urteil vom 13.06.2017 – Az. 4 U 72/16) diese Sicht jedoch korrigiert: Wenn die Software unter GPL steht und damit normalerweise gebührenfrei lizenziert wird, kann man nicht im Verletzungsfall plötzlich so tun, als hätte der Verletzer eine teure Lizenz zahlen müssen. Schadensersatz in Form einer fiktiven Lizenzgebühr lehnten die Richter ab. Das heißt praktisch: Bei OSS-Verstößen geht der Rechteinhaber in Sachen Geld meist leer aus, sofern er nicht nachweisen kann, dass ihm ein realer Schaden entstand. Dies mag frustrierend für Entwickler sein, aber es unterstreicht auch: Der Haupthebel der Open-Source-Lizenzen ist nicht der finanzielle Schaden, sondern die Verfügungsmacht (Stoppen der Nutzung). Wichtig: OLG Hamm hat nicht gesagt, dass jeglicher Schadensersatz ausgeschlossen ist – theoretisch könnte etwa ein Mitbewerber, der GPL-Code rechtmäßig nutzt, Wettbewerbsvorteile verlieren oder ähnliche Schäden darlegen. Aber so etwas ist schwer zu quantifizieren.

• Ersatz von Abmahnkosten: Wenn der Rechteinhaber berechtigt abmahnt, kann er Ersatz der notwendigen Rechtsverfolgungskosten verlangen (§ 97a Abs. 3 UrhG). Das umfasst Anwaltskosten für die Abmahnung, typischerweise berechnet nach einem Streitwert. In der Praxis wurden bei GPL-Verstößen Streitwerte durchaus im Bereich 50.000 – 100.000 € angesetzt (siehe z.B. LG München I im Jahr 2004 setzte 100.000 € an), was Anwaltskosten im mittleren vierstelligen Bereich bedeuten kann. Diese Kosten muss der Verletzer dann tragen, was einen durchaus spürbaren finanziellen Effekt darstellt, auch wenn kein Schadensersatz gezahlt wird.

• Vertragsstrafe: Hat der Verletzer eine Unterlassungserklärung mit Strafbewehrung abgegeben, muss er bei erneutem Verstoß eine vereinbarte Vertragsstrafe zahlen. Diese kann ebenfalls hoch sein (oft „vom Rechteinhaber nach billigem Ermessen festzusetzen, vom Gericht überprüfbar“ – was schnell fünfstellige Beträge ergeben kann). Das soll sicherstellen, dass der Verletzer nicht einfach weitermacht.

Neben zivilrechtlichen Folgen ist theoretisch auch Strafrecht relevant: Das unerlaubte Verwerten urheberrechtlich geschützter Werke kann nach § 106 UrhG strafbar sein, bei gewerbsmäßigem Ausmaß sogar härter (§ 108a UrhG). In der Praxis kommt es aber so gut wie nie zu Strafanzeigen wegen Open-Source-Lizenzverstößen – die Materie wird in aller Regel zivilrechtlich zwischen den Parteien geklärt, zumal die Verletzer meist Unternehmen sind und die Geschädigten Entwickler oder Stiftungen, die eher an Einhaltung der Lizenz interessiert sind als an Strafverfolgung.

Relevante Rechtsprechung in Deutschland

Die Durchsetzung von Open-Source-Lizenzen vor Gerichten hat in Deutschland einige Präzedenzfälle geschaffen. Hier einige der wichtigsten Entscheidungen und Fälle:

• LG München I, Beschluss vom 19.05.2004 (Az. 21 O 6123/04): Dies war eine der ersten gerichtlichen Bestätigungen der GPL in Deutschland. Der Entwickler Harald Welte (Projekt Netfilter/IPTables im Linux-Kernel) erwirkte eine einstweilige Verfügung gegen ein Unternehmen (Sitecom), das seine Software in Router-Firmware nutzte, ohne die GPL-Bedingungen einzuhalten. Das Gericht untersagte dem Unternehmen, die Software weiter zu verbreiten, solange nicht der GPL-Lizenztext beigelegt und der Source Code angeboten wird. Wichtig auch: Das LG München I stellte klar, dass das automatische Erlöschen der Lizenz bei Verstoß nicht gegen deutsches Recht verstößt. Insbesondere sei § 31 Abs. 1 S. 2 UrhG (wonach ausschließliche Lizenzen der Schriftform bedürfen) nicht umgangen, da hier ein einfaches Nutzungsrecht auflösend bedingt eingeräumt wurde, was zulässig ist. Dies war ein Meilenstein – die Wirksamkeit der GPL wurde damit anerkannt.

• LG Frankfurt a.M., Urteil vom 06.09.2006 (Az. 2-6 O 224/06): Ein weiteres wichtiges Urteil, in dem im Kern das gleiche bestätigt wurde: GPL-Verstöße führen zum Erlöschen der Nutzungsrechte (hier ausdrücklich unter Verweis auf § 158 Abs. 2 BGB, also die Regelung zu auflösenden Bedingungen), und diese Konstruktion ist nicht AGB-widrig.

• LG Köln, Urteil vom 16.05.2012 (Az. 33 O 353/11): Hier ging es um die Verbreitung von GPL-lizenzierter Firmware in Internetroutern. Das Gericht bejahte ebenfalls den Unterlassungsanspruch bei GPL-Verletzung. Interessant an dem Fall war, dass es um einen sog. „Downloader“ ging – also eine Kette von Unternehmen, die Software weitergaben. Das Urteil stellte klar, dass jeder in der Vertriebskette, der die Software weitergibt, die Lizenzpflichten erfüllen muss. Der Routerhersteller hatte zwar Quellcode angeboten, aber ein Online-Portal, das Firmware-Updates an Endnutzer verteilte, hatte dies versäumt – auch das war abmahnfähig.

• LG Bochum, Urteil vom 03.03.2016 (Az. I-8 O 294/15) und OLG Hamm, Urteil vom 13.06.2017 (Az. 4 U 72/16): Dieser Komplex betraf eine Universität, die Software (ursprünglich mal GPLv2, später proprietär lizenziert) zum Download anbot, ohne Quellcode. Das LG Bochum bejahte neben Unterlassung auch Schadensersatz in Form einer fiktiven Lizenzgebühr. Das OLG Hamm hob den Schadensersatz jedoch auf. Wie oben erwähnt, verneinte es einen solchen Anspruch, da keine Lizenzgebühr normalerweise anfallen würde. Dennoch bestätigte es, dass ein Urheberrechtsverstoß vorlag und die Nutzungsrechte entfallen waren. Somit blieb es bei Unterlassung und Kostentragung, aber ohne separaten Schadensersatz. Dieses OLG-Urteil wird oft zitiert als Hinweis, dass man bei OSS-Verletzung nicht automatisch mit hohen Geldstrafen rechnen muss – was aber nicht heißen sollte, dass es folgenlos wäre.

• OLG Karlsruhe, Urteil vom 27.01.2021 (Az. 6 U 60/20): Der bereits erwähnte WordPress-Theme-Fall. Hier stand weniger die Verletzung als solche im Fokus (die war implizit gegeben), sondern die Folgen: Verliert der Entwickler seine eigenen Rechte am Werk? Das OLG sagte klar: Nein, der „virale Effekt“ der GPL führt nicht dazu, dass jedermann die Bearbeitung nutzen darf ohne Zustimmung des Bearbeiters. Die GPL bewirkt „nur“ den Rechtsverlust an der ursprünglichen OSS (d.h. man darf den fremden Code nicht mehr nutzen), aber nicht automatisch eine Freigabe der neu geschaffenen Teile an die Allgemeinheit. Anders formuliert, Copyleft erzwingt nicht, dass der Quellcode gegen den Willen des Entwicklers öffentlich wird – es entzieht ihm nur die Erlaubnis, das Produkt weiter zu verbreiten, solange er die Offenlegung verweigert. Dieses Urteil brachte etwas mehr Rechtssicherheit dahingehend, dass ein Verletzer der GPL sich zumindest gegenüber Dritten noch auf sein Urheberrecht berufen kann. Für die Praxis heißt es: Die Strafe der GPL ist die Vertriebsblockade, nicht die Enteignung des Programmierers. Allerdings bleibt das Risiko, dass der Original-Rechteinhaber (z.B. WordPress-Autoren) seinerseits Unterlassung fordern könnte, wodurch das Theme letztlich ebenfalls nicht vertrieben werden dürfte.

• Hellwig ./. VMware (LG Hamburg 2015, OLG Hamburg 2019): Dieser prominente Fall zeigt die Schwierigkeit in komplexen Szenarien. Christoph Hellwig, ein Linux-Kernel-Entwickler, warf VMware vor, Teile seines (GPLv2-lizenzierten) Codes im proprietären VMware ESXi Hypervisor zu nutzen, ohne GPL-Konformität. Die Klage in Hamburg wurde letztinstanzlich abgewiesen, nicht weil die GPL unwirksam wäre, sondern aus Beweisgründen: Hellwig konnte nicht eindeutig nachweisen, welche Teile von VMware exakt auf seinem Beitrag basierten, da VMware zwar offen anerkannte, Linux-Code zu verwenden, aber auch behauptete, eigenständige Module geschrieben zu haben. Das Gericht scheute letztlich die grundsätzliche Frage, ob die Kombination ein abgeleitetes Werk darstellt, und urteilte mangels substantiierten Nachweises für den konkreten Code für VMware. Hellwig verzichtete danach auf weitere Rechtsmittel. Dieser Fall zeigt: In großen Projekten mit vielen Urhebern kann die Durchsetzung auch mal scheitern – was aber kein Freibrief für Verstöße ist, sondern oft nur heißt, dass der Druck dann anders ausgeübt wird (Community-Druck, Presse). Tatsächlich hat VMware parallel einige Schritte unternommen, Teile seines Codes zu öffnen oder neu zu strukturieren, um GPL-Konflikte zu entschärfen.

• Harald Welte und gpl-violations.org: Hierzu gibt es keine einzelne Entscheidung, sondern eine Reihe erfolgreicher Abmahnungen und einstweiliger Verfügungen (neben 2004 z.B. auch LG München 2005, LG Berlin 2010 etc.). Welte, als engagierter Entwickler, hat quasi bewiesen, dass man GPL-Verstöße konsequent verfolgen kann. Viele Hersteller von Embedded-Geräten (Router, DVD-Player mit Linux, etc.) wurden erwischt, die Lizenz nicht beachtet zu haben, und mussten nachbessern. In der Community sind diese Fälle berühmt-berüchtigt; juristisch haben sie die Durchsetzbarkeit von Open-Source-Lizenzen in Deutschland etabliert.

Zusammenfassend: Die Rechtsprechung hierzulande steht hinter Open-Source-Lizenzen. Wer glaubt, solche „freien“ Lizenzen würde keiner ernsthaft einklagen, irrt. Die Gerichte erkennen die Lizenzbedingungen als Vertragsbedingungen an und werten Verstöße als Urheberrechtsverletzung mit den genannten Ansprüchen. Gleichzeitig sind sie sich bewusst, dass es um freie Software geht – daher sind extreme Geldstrafen selten. Das Hauptinstrument ist die Unterlassung (und damit die Sicherstellung der offenen Verfügbarkeit des Codes oder die Einstellung der Nutzung).

Praktische Folgen für Entwickler und Unternehmen

Was bedeuten diese rechtlichen Risiken konkret im Alltag eines Entwicklerteams oder einer Firma?

• Produktverzögerung oder -stopp: Im schlimmsten Fall kann ein Lizenzverstoß dazu führen, dass ein ganzes Projekt gestoppt werden muss. Denken wir an ein Videospiel, das kurz vor Release steht, und plötzlich entdeckt jemand, dass ein Entwickler eine GPL-Bibliothek eingebaut hat, ohne das der Publisher wusste. Wenn das publik wird oder an den Lizenzgeber gemeldet, droht eine einstweilige Verfügung, die den Vertrieb untersagt. Das Spiel könnte nicht veröffentlicht werden, bis das Problem gelöst ist – entweder durch Entfernen der Komponente (was technisch kurz vor Release ggf. kaum machbar ist) oder durch Offenlegen des Codes (was dem Publisher nicht schmeckt). Beide Optionen können die Markteinführung erheblich verzögern oder wirtschaftlich ruinieren. Daher gilt: Lizenz-Compliance ist ein Teil des Qualitätsmanagements.

• Vertragsrisiko mit Auftraggebern: Wenn ein Studio im Auftrag eines Publishers ein Spiel entwickelt und dabei Lizenzverstöße produziert, kann der Publisher das als Vertragsbruch werten. Das kann Schadenersatzansprüche nach sich ziehen (etwa Kosten für nachträgliche Code-Refaktorierung oder Vertragsstrafen). Im B2B-Verhältnis kann der Lieferant haftbar gemacht werden, wenn er nicht für vertragsgemäße, rechtefreie Lieferung sorgt. (Dazu mehr im nächsten Abschnitt „Vertragliche Aspekte“.)

• Ausschluss von Vertriebsplattformen: In der Plugin-Welt – etwa WordPress, aber auch Browser-Add-on Stores etc. – kann ein Verstoß den Rauswurf aus dem Ökosystem bedeuten. Wenn etwa bekannt wird, dass ein WordPress-Plugin Code unter GPL nutzt, aber den eigenen Quellcode nicht anbietet, könnte WordPress das Plugin aus dem offiziellen Verzeichnis entfernen und öffentlich darauf hinweisen. Neben dem Vertriebsverlust entsteht ein Reputationsschaden: Entwickler gelten dann als unsauber arbeitend oder rechtlich unzuverlässig.

• Reputationsschaden bei Entwicklern: Gerade in der Entwickler-Community ist Open Source ein sensibles Thema. Firmen, die OSS-Lizenzen missachten, könnten öffentlich kritisiert werden (z.B. in Foren, Blogs, Heise-News etc.). Beispiele gab es einige: als bekannt wurde, dass bestimmte Produkte GPL-Verstöße enthielten, gab es mediale Aufmerksamkeit. In Zeiten von Social Media ist solch negative Publicity nicht zu unterschätzen.

• Kosten der Nachbesserung: Sollte es doch zu einer Abmahnung kommen, muss der Verletzer in der Regel nicht nur die Abmahnkosten tragen, sondern auch schnell handeln, um den Verstoß abzustellen. Das kann bedeuten: Entwicklerzeit investieren, um fehlende Lizenztexte hinzuzufügen, oder den Quellcode allen Kunden zur Verfügung zu stellen, oder gar Komponententausch. Diese Nacharbeiten binden Ressourcen und kosten Geld, sind aber notwendig, um größeren Schaden zu vermeiden. Im schlimmsten Fall muss ein Update für alle Kunden verteilt werden, was gerade bei Embedded-Geräten oder Spielen ohne automatisches Patching eine Herausforderung sein kann.

Insgesamt lässt sich sagen: Die Risiken bei Nicht-Einhaltung von Open-Source-Lizenzen sind real und vor allem geschäftskritisch. Sie können Projekte lahmlegen und Vertragsbeziehungen belasten. Die gute Nachricht: All dies ist vermeidbar, wenn man von Anfang an korrekt mit den Lizenzen umgeht. Open Source zu nutzen ist nicht per se gefährlich – man muss nur die „Spielregeln“ kennen und einhalten. Dann wird aus dem Risiko ein großer Nutzen.

Vertragliche Aspekte beim Einsatz von Open Source

Neben den unmittelbar urheberrechtlichen Fragen spielen auch vertragliche Regelungen eine große Rolle, wenn es um den Einsatz von Open Source in Softwareprojekten geht. Hier betrachten wir, wie in Verträgen – etwa zwischen Auftraggeber und Auftragnehmer, zwischen Arbeitgeber und Angestelltem Entwickler oder zwischen Software-Anbieter und Kunden – Open-Source-Aspekte berücksichtigt werden sollten. Stichworte sind Integrationsklauseln, Prüfpflichten und Due-Diligence-Klauseln, aber auch Themen wie Gewährleistung, Haftung und interne Richtlinien.

Regelungen in Software-Entwicklungsverträgen

Wenn ein Unternehmen eine Software (z.B. ein Spiel oder ein Plugin) bei einer Agentur oder einem Freelancer in Auftrag gibt, wird meist ein Werkvertrag oder ein ähnlicher Entwicklungsvertrag geschlossen. Darin wird festgelegt, was geliefert werden soll (Funktionalitäten, Leistungsmerkmale) und oft auch, welche Qualitätsstandards gelten. In den letzten Jahren ist es üblich geworden, in solchen Verträgen ausdrücklich festzuhalten, ob und in welcher Form Open-Source-Komponenten verwendet werden dürfen.

Typische Klauseln in diesem Zusammenhang sind zum Beispiel:

• Open-Source-Erlaubnis oder -Verbot: Manche Auftraggeber untersagen dem Auftragnehmer pauschal, Open-Source-Code zu verwenden, insbesondere solchen unter Copyleft-Lizenzen. Hintergrund ist die Sorge, dass die gelieferte Software sonst nicht frei nutzbar wäre oder Drittansprüche auslösen könnte. Ein Totalverbot ist allerdings oft unpraktikabel, da fast jede Software heute auf irgendeine Library zurückgreift. Daher formulieren viele Verträge differenzierter: „Der Auftragnehmer darf Open-Source-Software-Komponenten verwenden, sofern diese unter einer lizenzrechtlich kompatiblen Lizenz (z.B. MIT, BSD, Apache, LGPL) stehen und die Nutzung solcher Komponenten die vertragsgemäße Verwendung der gelieferten Software durch den Auftraggeber nicht einschränkt. Insbesondere ist der Einsatz von Copyleft-Lizenzen, die den Quellcode der gesamten Software offenzulegen verpflichten würden (insb. GPL, AGPL), nur nach ausdrücklicher schriftlicher Zustimmung des Auftraggebers zulässig.“ – Eine solche Klausel stellt klar, dass z.B. eine kleine MIT-Bibliothek okay ist, aber eine GPL-Bibliothek vorher genehmigt werden muss (was in der Regel verweigert würde, außer der Auftraggeber hat Gründe, es zu erlauben).

• Integrationsklausel / Drittsoftware-Klausel: Hier geht es darum, dass alle verwendeten Drittkomponenten (nicht nur OSS, auch kommerzielle Libraries) offengelegt werden. Etwa: „Der Auftragnehmer liefert dem Auftraggeber bei Ablieferung eine vollständige Liste aller verwendeten Drittsoftware-Komponenten inkl. Versionsnummer und Lizenz, sowie Kopien der jeweiligen Lizenzbestimmungen.“ Das sorgt für Transparenz. Der Auftraggeber kann dann selbst prüfen oder prüfen lassen, ob diese Lizenzen akzeptabel sind. Solche Klauseln sind Teil der Dokumentationspflicht. Sie schützen den Auftraggeber davor, unangenehme Überraschungen zu erleben und ermöglichen ihm ggf. auf problematische Komponenten hinzuweisen.

• Entire Agreement / Gesamtheit: Manchmal findet sich in Verträgen eine sogenannte Integrationsklausel im Sinne von „Dieser Vertrag stellt die gesamte Vereinbarung der Parteien dar; mündliche Nebenabreden existieren nicht.“ Was bedeutet das im Open-Source-Kontext? Es könnte relevant werden, wenn ein Auftragnehmer OSS einbaut, denn streng genommen „kommen“ damit ja Lizenzbedingungen Dritter ins Spiel – die OSS-Lizenz ist eine eigene Vereinbarung zwischen Rechteinhaber und Nutzer. Eine Integrationsklausel soll ausschließen, dass plötzlich dritte Bedingungen den Vertrag beeinflussen. Natürlich kann man mittels Zweiparteienvertrag die Pflichten gegenüber dem OSS-Urheber nicht aushebeln – die gelten unabhängig. Aber diese Diskrepanz kann Spannungen erzeugen: Im Innenverhältnis Auftraggeber–Auftragnehmer gilt, was im Vertrag steht (z.B. „keine Veröffentlichungspflicht“), im Außenverhältnis gegenüber dem OSS-Urheber gilt die GPL (die aber der Auftraggeber vielleicht gar nicht kennt). Daher ist es ratsam, im Vertrag explizit zu regeln, wie mit Open-Source-Lizenzen umzugehen ist, statt sie totzuschweigen. So vermeidet man, dass eine Integrationsklausel in Konflikt mit OSS-Bedingungen steht. Im Zweifel sollte der Auftragnehmer darauf hinweisen: „Achtung, diese Software enthält OSS mit folgenden Bedingungen – der Vertrag ändert daran nichts, wir müssen diese Bedingungen einhalten.“

• Rechteübertragung und OSS: Oft möchten Auftraggeber alle Rechte am Entwicklungsergebnis übertragen bekommen (exklusive Nutzungsrechte, § 31 UrhG). Wenn aber Open Source drinsteckt, kann der Auftragnehmer nicht mehr Rechte übertragen, als er selbst hat. Er kann dem Auftraggeber also nicht das ausschließliche Recht an einer Komponente geben, die unter GPL steht – denn diese Komponente bleibt ja Dritten unter GPL verfügbar. Verträge sollten daher klarstellen, dass für Open-Source-Bestandteile keine exklusiven Rechte übertragen werden (müssen), sondern der Auftraggeber sie im Rahmen der jeweiligen Lizenz nutzen darf. Manchmal formuliert man: „Soweit der Liefergegenstand Open-Source-Software enthält, gelten für diese Komponenten die Bedingungen der jeweiligen Open-Source-Lizenz. Der Auftraggeber erhält in diesem Rahmen die Nutzungsrechte, wie sie durch die Open-Source-Lizenz eingeräumt werden; eine weitergehende Rechtseinräumung ist nicht erforderlich und nicht möglich.“ Damit ist juristisch sauber abgedeckt, dass niemand gegen die Logik der OSS-Lizenz verstößt.

Prüfpflichten und Compliance-Prozesse

Prüfpflichten können in Verträgen oder internen Richtlinien festgehalten werden. Sie dienen dazu sicherzustellen, dass Open-Source-Lizenzen korrekt gehandhabt werden.

• Vertragliche Zusicherung der Prüfung: Ein Auftragnehmer könnte zusichern: „Wir haben alle verwendeten Komponenten auf Lizenzverträglichkeit geprüft.“ Oder ein Softwarelieferungsvertrag kann festhalten, dass der Lieferant garantiert, dass die Software frei von Open-Source-Komponenten ist, die einer Veröffentlichungspflicht oder sonstigen Beschränkung unterliegen. Solche Garantien geben dem Auftraggeber ein Sicherheitsversprechen. Wenn sich im Nachhinein herausstellt, es war doch nicht geprüft, kann das zu Ansprüchen führen (etwa Schadenersatz, Minderung).

• Audits und Tests: In manchen Verträgen, vor allem bei größeren Projekten, behält sich der Auftraggeber ein Audit-Recht vor. Beispielsweise darf der Auftraggeber den Code durch eigene Experten oder Tools prüfen lassen (z.B. mit einer Software Composition Analysis), bevor er die Abnahme erklärt. Findet er dann z.B. eine unerlaubte GPL-Komponente, kann er die Abnahme verweigern, bis das behoben ist. Das motiviert den Lieferanten, selbst vorzuliefern, was er nutzt.

• Unternehmensinterne Policies: Unabhängig von Verträgen mit Dritten sollten Unternehmen eigene Open-Source-Compliance-Richtlinien haben. Darin wird intern festgelegt, wie Entwickler vorzugehen haben, wenn sie Open Source einsetzen wollen. Z.B. kann ein Freigabeprozess definiert sein: Ein Entwickler muss jedes neue Open-Source-Paket in einer Liste anmelden, mit Angaben zur Lizenz, Zweck, Alternativen, und eine zuständige Person (etwa ein Open-Source-Compliance-Officer oder das Legal Team) gibt grünes Licht oder lehnt ab. Viele größere IT-Unternehmen praktizieren das. Zudem wird oft eine Liste erlaubter Lizenzen bereitgestellt (Whitelist) und evtl. eine Blacklist besonders problematischer Lizenzen (z.B. AGPL, oder manche mit tricky Klauseln). Das alles fällt unter „Prüfpflichten“ im weiteren Sinne – es ist die Sorgfalt, die man walten lassen muss, bevor man Code verwendet, der anderen gehört.

• Dokumentationspflicht: Schon angesprochen – aber auch intern muss lückenlos dokumentiert sein, welche OSS-Komponenten in einem Produkt stecken. Im Chaos eines Projekts kann es sonst passieren, dass man vergisst, was man vor Monaten eingebaut hat, und dann beim Release fehlen Bestandteile (etwa den richtigen Lizenztext mitzuliefern). Daher sollte eine Stückliste (Bill of Materials) geführt werden. In Verträgen kann auch der Liefergegenstand die Dokumentation einschließen, etwa: „Liefergegenstand ist der Quellcode der Software einschließlich einer Dokumentation aller Open-Source-Elemente und deren Lizenzbedingungen.“ Dann ist klar: ohne diese Liste ist die Lieferung unvollständig.

Gewährleistung und Haftung bei Open-Source-Einsatz

Nehmen wir an, ein Entwickler liefert Software an einen Kunden, und später stellt sich heraus, dort war eine OSS-Lizenz verletzt worden. Welche vertraglichen Ansprüche könnte der Kunde haben? Hier kommen Gewährleistung (Sach- und Rechtsmängel) und Haftungsregeln ins Spiel:

• Rechtsmangel: Nach § 435 BGB liegt ein Rechtsmangel vor, wenn Dritte in Bezug auf die gelieferte Sache Rechte geltend machen können, die der Verwendung durch den Käufer entgegenstehen. Übertragen auf Software: Wenn in der gelieferten Software Code enthalten ist, der nicht rechtmäßig genutzt werden darf (weil z.B. die Lizenz verletzt wurde), dann hat ein Dritter – der ursprüngliche Urheber – Ansprüche (Unterlassung etc.), die die vertragsgemäße Nutzung der Software beeinträchtigen. Das ist ein klassischer Rechtsmangel. Bei einem Rechtsmangel stehen dem Käufer/Gegenüber die Gewährleistungsrechte zu: Nacherfüllung, bei Scheitern Rücktritt oder Minderung, plus Schadensersatz bei Verschulden.

  Beispiel: Ein Plugin-Hersteller verkauft einem Unternehmen ein Plugin für dessen Webseite. Später erhält das Unternehmen eine Abmahnung von einem OSS-Entwickler, dass das Plugin gegen die GPL verstößt. Das Unternehmen musste das Plugin deaktivieren und verlangt nun vom Hersteller Abhilfe – entweder Lizenzkonformität herstellen oder Schadensersatz für den Nutzungsausfall. In so einem Fall würde man argumentieren: Der Plugin-Hersteller hat mangelhaft geliefert (Rechtsmangel), soll Nacherfüllung leisten (Plugin ohne Lizenzverstoß liefern, z.B. durch Update, das den Code austauscht) und ggf. dem Kunden entstandene Schäden ersetzen.

• Sachmangel: Man könnte auch an einen Sachmangel denken, wenn vertraglich zugesichert war, dass z.B. keine Open Source enthalten ist. Wenn dann doch welche drin ist, entspricht die Software nicht der vereinbarten Beschaffenheit – das wäre ein Sachmangel (§ 434 BGB). Oft wird aber die rechtliche Freistellung eher als Rechtsmangel qualifiziert. In jedem Fall: Der Lieferant muss nachbessern oder der Kunde hat Rechte.

• Haftungsklauseln: Verträge begrenzen meist die Haftung der Parteien, insbesondere für leichte Fahrlässigkeit. Allerdings können Kernpflichten nicht ausgeschlossen werden, und bei Vorsatz/Grobfahrlässigkeit oder zugesicherten Eigenschaften greift jeder Ausschluss nicht. Wenn also ein Entwickler bewusst oder grob fahrlässig eine Lizenz missachtet, kann er sich kaum auf Haftungsausschlüsse berufen. Andersherum, wenn ein Unternehmen Open-Source-Software von einem OSS-Projekt nutzt und diese hat z.B. einen Bug, greift meistens der in der OSS-Lizenz enthaltene Haftungsausschluss. Doch wie erwähnt, ein Total-Ausschluss der Haftung ist nach deutschem AGB-Recht eingeschränkt. Also könnte ein Nutzer eines OSS-Tools im Extremfall den Urheber haftbar machen, falls z.B. ein Vorsatz nachweisbar wäre (was extrem unwahrscheinlich ist). Praktisch spielen diese Überlegungen seltener eine Rolle, weil man in der Regel von OSS kein Gewährleistung erwartet (es wird „as is“ geliefert). Aber in B2B-Verträgen, wo OSS Bestandteile drin sind, ist wichtig: Der Lieferant kann nicht einfach jegliche Verantwortung ablehnen mit dem Hinweis „da war halt OSS drin, da gilt Gewährleistungsausschluss“. Dem Endkunden gegenüber bleibt der Lieferant in der Pflicht, außer es wurde im Vertrag ausdrücklich anders geregelt.

• Indemnifizierung: In internationalen Verträgen (gerade mit US-Unternehmen) sieht man häufig Indemnity-Klauseln: der Lieferant stellt den Kunden von allen Ansprüchen Dritter frei, die aus Verletzung von IP-Rechten resultieren, und übernimmt Verfahrenskosten usw. Überträgt man das auf OSS, bedeutet das: Wenn ein Open-Source-Urheber den Kunden wegen eines Lizenzverstoßes belangt, muss der Lieferant einspringen und den Kunden schützen/entschädigen. Eine solche Klausel erhöht natürlich den Druck auf den Lieferanten, von vornherein auf Compliance zu achten, da er sonst teuer haften muss. In deutschen Verträgen ist der Begriff „Freistellung“ oder „Haftungsfreistellung“ auch gebräuchlich. Ein Auftraggeber könnte verlangen: „Der Auftragnehmer stellt den Auftraggeber von allen Ansprüchen Dritter aufgrund von Verletzungen von Urheber- oder Lizenzrechten durch die gelieferte Software frei.“ Damit wälzt er das Risiko vollständig nach hinten ab.

Zusammengefasst: Vertraglich sollte man beim Einsatz von Open Source klare Regelungen treffen, um alle Parteien abzusichern. Der Entwickler/Lieferant will wissen, was er darf und dass ihm nicht im Nachhinein vorgeworfen wird, er habe unzulässiges getan, wenn es doch erlaubt war. Der Auftraggeber will sicher sein, dass das Produkt keine „Lizenzbombe“ enthält, die ihm später hochgeht. Gute Verträge und offene Kommunikation über eingesetzte OSS schaffen hier Vertrauen und vermeiden Streit.

Due Diligence bei M&A und Transaktionen

Ein weiteres wichtiges Feld: Due Diligence in Unternehmensübernahmen und Investments. Wenn ein Investor eine Softwarefirma kaufen möchte, prüft er natürlich deren Technologie. Dabei ist inzwischen Standard, auch die Open-Source-Compliance unter die Lupe zu nehmen. Warum?

Stellen wir uns vor, Investor X will ein Spielestudio kaufen, das ein erfolgreiches proprietäres Spiel hat. Wenn sich nach dem Kauf herausstellt, dieses Spiel enthält unbeachteten GPL-Code, muss der neue Eigentümer eventuell den Quellcode veröffentlichen oder den Vertrieb stoppen, bis es gefixt ist – das könnte den Wert des ganzen Investments massiv mindern. Daher werden vor Abschluss eines Kaufvertrages verschiedene Prüfungen (Due Diligence) gemacht:

• Code-Scan: Es gibt spezialisierte Dienstleister, die den gesamten Code der Zielgesellschaft scannen (mittels Tools wie Black Duck, FOSSID etc.) und einen Report erstellen, welche Open-Source-Komponenten identifiziert wurden, mit Lizenzinformationen. Auch nicht deklarierte Komponenten lassen sich so oft aufspüren.

• Policy-Check: Der Käufer prüft, ob das Unternehmen Richtlinien im Umgang mit OSS hat, wie das Compliance-Management aufgestellt ist, ob in der Vergangenheit irgendwelche Verstöße oder Abmahnungen vorlagen. Ein reifer OSS-Compliance-Prozess ist ein gutes Zeichen, dass wenig Risiken schlummern.

• Verträge: Man schaut sich die Verträge an, ob bei Zulieferern oder Partnern Klauseln existieren, die evtl. verletzt sein könnten wegen OSS (wie die oben genannten Verbote). Wenn z.B. das Unternehmen Software an Großkunden geliefert hat mit Zusicherung „keine Copyleft-Software enthalten“, sollte der Prüfer sicherstellen, dass das auch der Wahrheit entspricht, sonst drohen Nachhaftungen.

• Open-Source-Bilanz: Manche erstellen eine Liste aller OSS mit Ampelbewertung – grün (okay), gelb (vorsicht, z.B. LGPL oder MPL, die aber manageable sind), rot (GPL, AGPL, inkompatible Lizenzen). Gibt es rote Einträge, wird der Kaufpreis evtl. nachverhandelt oder der Verkäufer muss vor Closing diese Komponenten ersetzen (Refactoring).

In Deutschland hat es Fälle gegeben, wo z.B. der Verkauf eines Unternehmens verschoben wurde, bis es eine saubere Open-Source-Bilanz hatte. Kein Käufer will kurz nach dem Deal eine böse Überraschung erleben. Das gilt nicht nur beim Kauf eines ganzen Unternehmens, sondern auch beim Erwerb von einzelnen Software-Produkten oder beim Einstieg eines Investors.

Selbst wenn man nicht an Verkauf denkt: Partnerschaften und Vertriebslizenzen können ähnliche Prüfungen auslösen. Beispielsweise will ein großer Publisher ein Indie-Studio unter Vertrag nehmen. Der Publishing-Vertrag könnte eine Klausel haben: „Der Entwickler garantiert, dass das Spiel keine Open-Source-Software enthält, die die Ausübung der Verwertungsrechte des Publishers beeinträchtigt. Der Entwickler hat dem Publisher gegenüber alle Open-Source-Komponenten offenzulegen.“ Auch hier im Grunde eine Due Diligence seitens des Publishers, bevor er Marketingmillionen in das Spiel steckt.

Dokumentation und Weitergabe von Lizenzinformationen

Ein eher praktisches, aber vertragsnahes Thema: Weitergabe von Lizenzinformationen an Endnutzer. Viele Open-Source-Lizenzen verpflichten nicht nur den Entwickler zur Einhaltung, sondern auch, dass Endnutzer über bestimmte Dinge informiert werden. Beispielsweise verlangt die GPL, dass jeder Empfänger der Software ebenfalls die Lizenzbedingungen erhält und über seine Rechte (z.B. Quellcode-Anforderung) informiert wird. Oder Apache/MIT verlangen, dass der Lizenztext in der Dokumentation beigefügt ist, die ja letztlich beim Endnutzer ankommen muss.

Daher sollte bei der Softwareauslieferung folgendes sichergestellt sein (und vertraglich eingefordert werden):

• Beipack der Lizenzen: Der Lieferant sollte alle relevanten Lizenztexte mitliefern. Häufig wird vereinbart, dass in der Dokumentation oder Hilfedatei ein Abschnitt „Open Source Lizenzen“ enthalten sein muss. Gerade bei Spielen kann das auch im Menü „Credits“ oder „Legal Notices“ erfolgen. Wichtig ist, dass es im finalen Produkt zu finden ist. In physischen Produkten (z.B. ein Gerät mit Software) legt man oft ein Heftchen oder CD bei, in dem die Open-Source-Lizenzen abgedruckt sind.

• Source-Code-Bereitstellungspflicht: Wenn eine Komponente unter GPLv2 im Produkt ist, muss der Anbieter physisch oder elektronisch den Quellcode beilegen oder zumindest auf Anforderung zusenden. Bei GPLv3 muss ein schriftliches Angebot oder ein passender Link mitgeliefert werden, der für mindestens 3 Jahre gültig ist. Diese logistischen Pflichten sollte man in der Projektplanung bedenken. Wer z.B. ein IoT-Gerät produziert, das Linux (GPLv2) enthält, muss dem Endkunden entweder direkt den Source auf CD mitgeben oder zumindest in der Anleitung schreiben „Den Quellcode finden Sie unter [URL] oder können Sie bei uns anfordern“. Versäumt man das, ist man schon in Verletzung. Gute Praxis: gleich ein Webportal einrichten, wo alle OSS-Komponenten und Source zum Download bereitstehen – dann kann man in allen Produkten auf diese Seite verweisen.

• Vertragsstrafen im Weitervertrieb: Falls ein Unternehmen Software an einen Reseller oder Distributor gibt, sollte es auch diesen vertraglich verpflichten, die OSS-Hinweise weiterzugeben. Nicht dass am Ende der Hersteller sagt „Ich hab dem Distributor alles gegeben“, aber der Distributor vergisst, die Lizenzen dem Endkunden zu geben, und dann wird der Hersteller trotzdem verantwortlich gemacht. Daher werden in Vertriebspartnerverträgen manchmal Klauseln aufgenommen, die den Partner dazu verpflichten, keine Lizenztexte zu entfernen und alle notwendigen Unterlagen weiterzugeben. Auch ein Hinweisverbot könnte kontraproduktiv sein: Man darf dem Partner natürlich nicht vertraglich verbieten, auf OSS hinzuweisen, weil das muss ja geschehen. Also solche Feinheiten gehören berücksichtigt.

Umgang mit Copyleft in Verträgen

Es sei nochmal explizit erwähnt: Copyleft-Komponenten wie GPL in einem Auftrag sollten sehr bewusst und transparent gehandhabt werden. Wenn der Auftraggeber zustimmt, z.B. weil es keine Alternative gibt und er bereit ist, den Code offen zu verteilen, dann sollte im Vertrag genau festgehalten werden, wie diese Offenlegung erfolgt und dass der Auftraggeber das weiß. Eventuell regelt man, wer die Quellcode-Requests später bearbeitet (der Auftragnehmer im Namen des Auftraggebers oder der Auftraggeber selbst).

Wenn der Auftraggeber nicht damit einverstanden wäre, sollte der Auftragnehmer keinesfalls eigenmächtig so eine Komponente nutzen. Falls er es doch tut (vielleicht in der Hoffnung, es fällt nicht auf), bewegt er sich auf sehr dünnem Eis – er riskiert neben rechtlichen Schritten vom OSS-Urheber auch eine Vertragsverletzung dem Kunden gegenüber.

In Angeboten kann es hilfreich sein, schon zu sagen „Wir setzen folgende Open-Source-Tools ein…“, damit der Kunde Bescheid weiß. Transparenz schafft Vertrauen und reduziert späteren Streit.

Beispiel aus der Praxis

Angenommen, eine Agentur entwickelt ein webbasiertes Game für einen Kunden. Sie möchte ein bestimmtes JavaScript-Framework nutzen, das unter GPL steht. Der Kunde will aber das Spiel exklusiv und den Code geheim halten. Die Agentur findet keine vergleichbare Alternative und schlägt vor, das Framework dennoch zu nutzen, aber getrennt als Backend-Service zu betreiben. Im Vertrag vereinbaren sie, dass das Framework auf einem separaten Server läuft und der Code dafür dem Kunden samt GPL-Lizenz übergeben wird, während das eigentliche Spiel davon entkoppelt ist. Außerdem wird festgehalten, dass der Kunde bewusst dieser GPL-Nutzung zustimmt und den Quellcode des Framework-Teils auf Anfrage an Dritte herausgeben wird. – Dieses konstruiertes Beispiel zeigt, wie man notfalls auch mit Copyleft arbeiten kann, wenn man es vertraglich sauber aufgleist. Idealerweise hätte man aber einfach ein anderes Framework genommen.

Besonderheiten bei der Plugin-Entwicklung (WordPress, Shopify & Co.)

Zum Abschluss der inhaltlichen Abschnitte wollen wir noch spezifisch auf Plugins und die Entwicklung für Plattformen eingehen, da diese Zielgruppe besonders genannt wurde. Plugin-Entwickler bewegen sich oft in einem Ökosystem, das eigene Lizenzregeln hat, und müssen sowohl die Plattform-Policy als auch die OSS-Lizenzen berücksichtigen.

WordPress und GPL – unumgängliche Verbindung

WordPress als Content-Management-System ist eines der bekanntesten Beispiele, wo die Plattformlizenz die Plugins beeinflusst. WordPress steht unter GPLv2 (mit der Zusatzklausel „oder höher“, was aber im Zweifel GPLv2 meint, da WP bisher nicht offiziell auf GPLv3 umgestellt hat). Die WordPress Foundation hat klargestellt, dass sie Plugins und Themes als Derivate betrachtet. Praktisch bedeutet das:

• Plugins, die im offiziellen Verzeichnis gelistet werden, müssen GPL-kompatibel sein. Die häufigste Wahl ist einfach ebenfalls GPLv2 (oder v3). Viele Entwickler übernehmen exakt die gleiche Lizenz wie WordPress, um auf der sicheren Seite zu sein.

• Auch wenn ein Entwickler ein Plugin kommerziell verkauft (z.B. Premium-Plugins außerhalb der offiziellen Seite), stehen die meisten dennoch unter GPL. Und das ist zulässig: Die GPL erlaubt Verkauf, solange Lizenz und Code offen bleiben. Viele Plugin-Anbieter finanzieren sich über Support, Updates oder Zusatzdienste, nicht über restriktive Lizenzen. Der Endkunde kauft also z.B. eine Jahreslizenz für Updates, aber der Code, den er bekommt, ist GPL – theoretisch könnte er ihn weitergeben. In der Praxis tun das die wenigsten Endkunden, weil sie den Supportwert schätzen.

• Versuche, WordPress-Plugins/Themes anders zu lizenzieren, haben zu Konflikten geführt. Es gab den Fall von Theme-Entwicklern (z.B. einige auf ThemeForest), die den PHP-Code unter GPL stellten – um den WordPress-Regeln zu genügen – aber CSS/JS/Design unter eine proprietäre Lizenz packten, um zumindest einen Teil „zu schützen“. Die Rechtmäßigkeit ist umstritten: Streng genommen könnten auch Layout und JS als Teil des abgeleiteten Werks betrachtet werden, weil sie zusammen mit dem PHP-Code das Theme ergeben. WordPress hat zwar toleriert, dass Marketplaces diese Aufteilung machen, aber fördert weiterhin die rein GPL-Lizenzierung. Aus Entwickler- und Nutzersicht ist ein vollständig GPL-lizenziertes Theme/Plugin am unkompliziertesten, weil man genau weiß, woran man ist.

• Ein Wort zu Forks: Wenn ein Plugin GPL ist, darf jeder es forken und selbst vertreiben. Das geschieht tatsächlich – es gibt Seiten, die „GPL Plugins“ anbieten, also gekaufte Premium-Plugins dort günstiger oder kostenlos weiterverteilen. Das ist legal nach GPL, so lange sie nicht behaupten, es selbst geschrieben zu haben (Urhebernennung muss bleiben). Für die originalen Entwickler ist das natürlich lästig, aber sie bekämpfen es primär durch besseren Service (offizielle Updates, Support nur für zahlende Kunden, etc.). Lizenzrechtlich können sie nichts dagegen tun, da GPL das erlaubt. Plugin-Entwickler müssen sich also bewusst sein: Wenn ich fürs WordPress-Ökosystem entwickle, akzeptiere ich im Grunde GPL und die damit einhergehende Offenheit.

• Fallstudie: OLG Karlsruhe 2021 (nochmals kurz): Hier hat der kommerzielle Theme-Entwickler erfolgreich verhindert, dass jemand anders seinen Code veröffentlicht. Aber man darf das nicht so interpretieren, dass sein proprietäres Vorgehen damit abgesegnet wurde. Er hat sich quasi auf ein formales Eigentumsrecht zurückgezogen. Hätten die WordPress-Urheber ihn verklagt, wäre das Ergebnis anders ausgefallen (dann hätte er vermutlich unterliegen müssen und sein Theme freigeben oder Vertriebsstopp akzeptieren).

• Entwickler von WordPress-Plugins müssen zudem aufpassen, welche fremden OSS-Bibliotheken sie in ihr Plugin integrieren. Denn neben dem WP→Plugin-Lizenzfluss gibt es auch Plugin→dritter Code. Ein WP-Plugin kann z.B. eine MIT-JavaScript-Library einbinden – das ist okay (MIT ist GPL-kompatibel). Was, wenn ein Plugin eine LGPL-Bibliothek nutzt? Wahrscheinlich okay, da GPL>=LGPL in Kompatibilität, aber man müsste streng genommen die LGPL-Bedingungen auch erfüllen (z.B. Hinweise auf Änderungen an der Lib). Was, wenn ein Plugin eine PL-Bibliothek nutzt, die nicht GPL-kompatibel ist? Dann hat der Plugin-Entwickler selbst ein Kombinationsproblem: er kann sein Plugin nicht regelkonform veröffentlichen, weil er gleichzeitig WP (GPL) und diese inkompatible Komponente vereint. Also auch hier wieder: alle Komponenten im Plugin müssen zueinander passen. Gute Nachricht: Es gibt riesige Mengen an GPL-kompatibler OSS, sodass man selten gezwungen wäre, was Unpassendes zu nehmen.

Shopify und proprietäre Plattformen

Shopify ist ein anderes Biest: Eine geschlossene SaaS-Plattform für E-Commerce, deren Code nicht offen liegt. Entwickler können aber Apps oder Themes für Shopify erstellen. Die rechtlichen Bedingungen kommen hier aus zwei Richtungen: Zum einen die Shopify-eigenen Verträge (Partnerprogramm, API-Lizenzbedingungen etc.), zum anderen die eventuelle Nutzung von OSS in der App.

• Lizenz der Plattform: Shopify stellt APIs bereit, und dort wird in der Regel geregelt, dass man als Entwickler keine Rechte von Shopify verletzt. Shopify selbst ist nicht Open Source, daher existiert auch keine Copyleft-Pflicht von Plattform→App. Theoretisch könnte Shopify sogar verbieten, Open-Source-Komponenten zu nutzen, aber das tun sie meines Wissens nicht direkt. Sie interessieren sich eher dafür, dass die Apps sicher und legal sind.

• Nutzung von OSS in Shopify-Apps: Eine Shopify-App besteht oft aus zwei Teilen: dem Backend (auf dem Server des Entwicklers oder einer Cloud-Funktion, die Anfragen vom Shopify-Shop entgegennimmt und verarbeitet) und dem Frontend-Teil (z.B. eingebetteter Admin-UI oder Scripts, die in den Shop geladen werden).

  • Der Backend-Teil läuft remote. Wenn dort eine GPL-Komponente eingesetzt wird, wird sie nicht an Shopify oder den Händler „vertrieben“ – sie läuft ja nur auf dem Server des App-Entwicklers. Das wäre vergleichbar mit einem Webservice: GPL hat hier keine Handhabe (außer es ist AGPL). Der Entwickler muss also streng genommen den Source nicht veröffentlichen, solange er es nur als Service betreibt. Das war ein Grund, warum AGPL erfunden wurde: GPL konnte die SaaS-Nutzung nicht „fangen“. Sollte der Entwickler aber die App später on-premise beim Kunden installieren wollen (seltener bei Shopify), dann würde es zur Distribution kommen und GPL würde greifen.

  • Wenn der Entwickler allerdings AGPL-Komponenten in seinem App-Backend nutzt, muss er laut Lizenz auch den Quellcode gegenüber den Nutzern des Service offenlegen. In dem Fall wären die Nutzer die Shop-Betreiber oder Endkunden, die interagieren. Das passt meistens nicht mit einem kommerziellen App-Modell zusammen, daher ist AGPL in SaaS-Startups ziemlich gefürchtet. Shopify-Apps werden typischerweise keine AGPL enthalten, weil es dem Entwickler nichts nützt – er würde nur Pflichten auslösen.

  • Der Frontend-Teil der App: Das könnte JavaScript, CSS, Liquid-Templates sein, die in den Shop des Kunden integriert werden. Diese werden tatsächlich an den Kunden ausgeliefert (z.B. als Teil der Theme oder im Browser). Wenn hier OSS-Code enthalten ist, greift wieder Distribution. Ein Entwickler könnte z.B. ein JS-Widget unter MIT benutzen; das müsste dann mit dem MIT-Hinweis im Code belassen werden. Wenn er z.B. eine UI-Komponente unter GPL nutzen wollte (unwahrscheinlich, aber angenommen), dann würde er damit dem Händler eine GPL-Komponente mitgeben, was wiederum bedeuten würde, der Händler hat das Recht auf Quellcode etc. Der Händler würde sich wundern, was er damit soll, und Shopify selbst würde es vermutlich nicht erlauben, weil es verwirrend wäre.

  • Shopify selbst schreibt in den Partner-Program-AGBs, dass der Entwickler sicherstellen muss, alle nötigen Rechte an seiner App zu haben und nichts Rechtswidriges zu tun. Ein eklatanter OSS-Verstoß könnte theoretisch als Verstoß gegen diese AGB gelten, was zur Suspendierung des Entwicklerkontos führen könnte. Praktisch dürfte das aber nur passieren, wenn es öffentlich auffällt oder Shopify Beschwerden erhält.

  • Anders als WordPress erzwingt Shopify keine bestimmte Lizenz für Apps. Die App-Entwickler können ihre App quelloffen machen, müssen es aber nicht. Viele halten ihren Code proprietär (auch wenn Kunden letztlich den ausgeführten Code einsehen könnten, zumindest den Frontend-Teil). Hier muss der App-Entwickler gut abwägen, was er an Open Source einbaut, um nicht unbeabsichtigt etwas preiszugeben.

• Themes auf Shopify: Shopify erlaubt auch individuell gestaltete Themes, die man verkaufen kann. Themes sind letztlich Code (Liquid Templates, CSS, JS). Die Lizenz dieser Themes bestimmen die Ersteller; Shopify schreibt nichts wie „muss open source sein“. Folglich finden wir hier oft kommerzielle Lizenzen. Wenn ein Theme-Entwickler aber z.B. einen Slider unter GPL in sein Theme integriert, dann hat er das gleiche Problem wie bei WordPress: Entweder er muss den Slider-Code (und somit das Theme, das davon abhängt) unter GPL stellen, oder er verstößt. Da Shopify aber von sich aus nicht GPL ist, und der Slider-Urheber wahrscheinlich nicht merkt, könnte es durchrutschen – legal sauber ist es aber nicht. Es gibt jedoch haufenweise permissive Slider-Libraries etc., so dass man GPL-Teile in Shopify-Themes wohl leicht vermeiden kann.

Kurzum für Shopify-Entwickler: Auf der Plattform gibt es mehr Freiheit, proprietär zu bleiben, aber die Verantwortung für genutzte Open-Source-Bausteine liegt komplett beim App-Entwickler. Er sollte ebenso sorgfältig prüfen: Welche Lizenz hat jede Library, die ich einbaue? Erfülle ich deren Anforderungen (z.B. füge ich Copyright-Hinweise in Minified JS ein etc.)? Was passiert, wenn ich die App mal einem Kunden zum Self-Hosting gebe? Und natürlich: Habe ich etwas, das gar nicht kompatibel ist mit meiner Closed-Source-App (z.B. GPL)? Wenn ja, dringend ersetzen.

Andere Plattformen und Plugins

• Browser-Extensions: Sie sind oft Open Source oder enthalten OSS (z.B. UI libraries). Browser haben keine vorgeschriebene Plugin-Lizenz, aber z.B. der Chrome Web Store hat Richtlinien zur Copyright-Einhaltung. Wenn jemand fremden Code reinkopiert ohne Lizenz, kann das ein Problem werden. Insofern gelten auch hier die allgemeinen Regeln: nutzt OSS, aber haltet Euch an die Lizenz.

• Game-Modding und SDKs: Manche Spiele erlauben Mods oder Plugins via SDKs. Das Hauptspiel ist meist proprietär, aber die Mods können Lizenzen tragen. Oft sagen EULAs, dass Mods nur nicht-kommerziell sein dürfen und Rechte an den Publisher fallen etc. Das kollidiert wiederum mit OSS-Lizenzen, die keine Nutzungsbeschränkungen erlauben (GPL z.B. sagt, jeder darf für jeden Zweck nutzen, ein „nicht-kommerziell“ Verbot wäre GPL-widrig). Hier muss man aufpassen: Wenn ein Modder GPL-Code in einen Mod steckt, aber das Spiel EULA sagt „keine kommerzielle Nutzung“, hat man widersprüchliche Bedingungen. Das ist ein weites Feld – aber erwähnenswert, dass es in der Praxis Spannungen gibt. Modder sollten dann lieber permissive Lizenzen wählen oder gleich Public Domain, um sich keinen Stress einzuhandeln.

• App Stores allgemein: Egal ob Apple App Store, Google Play, Shopify App Store oder WordPress Repository – Plattformbetreiber wollen in der Regel nicht für Lizenzverletzungen ihrer Entwickler haften. Deswegen legen die Developer Terms fast immer Verantwortlichkeit beim Entwickler fest. Es liegt also an jedem Entwickler, sicherzustellen, dass er keine Rechte Dritter verletzt. Offene Lizenzen sind Rechte Dritter! Also ja, es ist relevant.

Praktische Empfehlungen für Entwickler und Unternehmen

Nach der ganzen Theorie und Fallstricke hier einige praxisnahe Tipps, wie man als Softwareentwickler – sei es im Game Development, in Plugin-Projekten oder generell – Open Source rechtssicher einsetzen kann, ohne dabei die kreativen und produktiven Vorteile missen zu müssen:

1. Kenntnis und Sensibilisierung: Mache dich mit den Grundlagen der wichtigen Lizenzen vertraut. Jeder Entwickler muss kein Jurist sein, aber ein Grundverständnis, was GPL vs. MIT bedeutet, sollte vorhanden sein. Viele Firmen schulen ihre Entwickler kurz dazu. Es hilft, wenn Begriffe wie „Copyleft“ oder „GPL-kompatibel“ keine böhmischen Dörfer sind. Insbesondere neu eingestellte Entwickler oder Freelancer sollten gebrieft werden, damit sie nicht unwissentlich problematischen Code einbringen.

2. Lizenzauswahl vor Nutzung: Bevor du eine Open-Source-Bibliothek in dein Projekt einbaust, prüfe die Lizenz. Lies den Lizenztext (zumindest überfliegen) oder schau auf Zusammenfassungen. Achte auf Schlüsselwörter: „GNU GPL“ – Alarm, schau genauer, ob das im Projekt passt. „MIT / BSD / Apache“ – meist unkritisch, aber notiere es dir. Wenn du unsicher bist, ob die Lizenz kompatibel ist, frage Kollegen oder im Zweifel Rechtskundige. Im Internet gibt es auch Foren (z.B. StackExchange „Open Source“), wo solche Fragen oft diskutiert werden.

3. Dokumentiere alle Drittkomponenten: Führe eine Liste (z.B. in der README des Projekts oder einem speziellen Dokument) aller externen Libraries, Snippets, etc., die nicht Eigenentwicklung sind. Notiere die Version und die Lizenz. Das erleichtert am Ende das Erstellen der „dritten Lizenzen“-Datei und stellt sicher, dass nichts vergessen wird. Es verhindert auch, dass später jemand versehentlich eine Komponente updatet, die Lizenz hat sich geändert, und keiner merkt’s – du hast es dokumentiert und wirst es bemerken.

4. Erfülle Lizenzbedingungen sofort: Am besten bereits während der Entwicklung sicherstellen, dass man die Pflichten umsetzt. Z.B. wenn du weißt, du benutzt MIT-Lizenzen, dann integriere doch gleich im About-Fenster oder im Hilfemenü einen Abschnitt „Open-Source Credits“, wo du die Namen und Lizenztexte aufführst. Nicht erst am Tag vor Release hektisch zusammensuchen. Bei GPL-Komponenten – plane von Anfang an, wo du den Quellcode zum Download anbietest oder wie du ihn dem Nutzer zukommen lässt. Das sollte kein Nachgedanke sein, sondern Teil des Release-Prozesses. Moderne Build-Pipelines haben oft Schritte, die automatisch eine OSS-Lizenzübersicht generieren können; nutze solche Automatisierungen.

5. Wähle bewährte OSS mit Community: Das ist mehr ein strategischer Tipp. Häufig genutzte Open-Source-Projekte haben meist auch gut dokumentierte Lizenzinformationen und bekannte Umgangsweisen. Ein exotisches Projekt mit einer selbstgestrickten Lizenz birgt mehr Unsicherheit. Also greif lieber zu populären Bibliotheken mit bekannten Lizenzen. Die Wahrscheinlichkeit ist geringer, dass du über eine seltsame Klausel stolperst. Außerdem sind populäre Projekte meist auf möglichst breite Nutzbarkeit aus, sprich eher permissiv oder zumindest LGPL.

6. Aufpassen bei Copy-Paste von Code: Viele Entwickler bedienen sich von Stack Overflow oder GitHub-Gist für kleine Code-Schnipsel. Beachte: Stack Overflow-Beiträge stehen unter CC-BY-SA (Creative Commons Namensnennung-Weitergabe-Lizenz). Das ist keine typische Softwareslizenz und kann problematisch sein, weil sie Weitergabe unter gleichen Bedingungen fordert (ähnlich Copyleft) und Nennung des Autors. Kleine Code-Stücke daraus – manche argumentieren, das sei de minimis (geringfügig) und nicht schutzfähig, aber verlassen sollte man sich darauf nicht. Besser: Wenn man Signifikantes übernimmt, den Urheber fragen oder zumindest in den Code-Kommentaren erwähnen. Bei GitHub Gists oder Projekten ohne Lizenzangabe gilt im Zweifel All Rights Reserved – sprich, Finger weg oder Lizenz erfragen, denn ohne ausdrückliche Lizenz hast du kein Nutzungsrecht! Kurz: Nicht gedankenlos Code aus dem Internet kopieren, nur weil er „da“ ist. Immer klären, unter welcher Lizenz er steht.

7. Mit gutem Beispiel vorangehen: Wenn du selbst Code veröffentlichst (sei es ein kleines Plugin auf GitHub oder ein Beitrag zu einer Library), wähle eine klare Lizenz und packe eine LICENSE-Datei dazu. So trägst du zur allgemeinen Kultur bei, dass Code nur mit Lizenz rumliegt. Und du erleichterst anderen, deinen Code ggf. in ihren Projekten zu verwenden. Gerade Plugin-Entwickler auf GitHub sollten nicht vergessen, ihr Repo zu lizenzieren – sonst dürfte eigentlich kein anderer es verwenden.

8. Open-Source-Compliance Tools einsetzen: Für größere Projekte oder Unternehmen lohnt es, Tools wie FOSSID, Black Duck, FOSSA, ORT etc. zu verwenden. Diese scannen den Code und erstellen Berichte zu Lizenzen. Sie erkennen auch Code-Teile, die aus OSS stammen könnten (durch Mustervergleich), selbst wenn kein Hinweis im Code ist. Das kann z.B. auffliegen lassen, dass jemand vor Jahren mal einen Code-Block aus einer GPL-Software kopiert hat. Solche Tools sind nicht 100% fehlerfrei, aber eine große Hilfe. Es gibt auch Open-Source-Werkzeuge, wie OSS Review Toolkit oder einfache Skripte, die mit npm oder pip oder maven integriert sind, um abhängige Libraries und deren Lizenzen aufzulisten.

9. Lizenz-Blacklist/Whitelist führen: Intern kann man definieren, welche Lizenzen problemlos genutzt werden dürfen und welche nur mit Genehmigung oder gar nicht. Beispiel: „Whitelist: MIT, BSD, Apache, MPL, LGPL“ (frei zu verwenden); „nur nach Freigabe: GPLv2/v3, AGPL, EPL…“; „Blacklist: keine unbekannten, keine ,Commons Clause’, keine DIY-Lizenzen“. Das hilft Entwicklern, sich zu orientieren. Achte aber darauf, diese Listen aktuell zu halten und zu begründen, damit Entwickler verstehen, warum z.B. GPL auf Rot steht (eben wegen der Verpflichtungen).

10. Upstream und Community: Wenn du Open-Source-Komponenten nutzt, halte dich nicht nur minimal an die Pflichten, sondern sei im Idealfall ein „guter Bürger“ der Open-Source-Community. Das heißt: Gib Verbesserungen, die du an der Library vornimmst, möglichst upstream (zurück an die Maintainer), anstatt sie closed-source in deinem Projekt zu belassen (sofern das möglich ist – bei GPL müsstest du es eh geben, aber auch bei MIT ist es ein netter Zug). Warum? Zum einen erspart dir das Pflegeaufwand, wenn deine Änderungen in die Hauptversion einfließen. Zum anderen stärkt es das Verhältnis zwischen Unternehmen/Entwicklern und Open-Source-Community. Im Falle eines versehentlichen Verstoßes wird man mit dir wahrscheinlich kooperativer umgehen, wenn du zuvor als fairer Open-Source-Nutzer aufgefallen bist, statt als jemand, der nur nimmt.

11. Juristischen Rat einholen bei Unsicherheit: Die Materie kann kompliziert sein – insbesondere bei Spezialfällen (z.B. Kombinationsfragen, Umgang mit verschärften Lizenzen oder wenn man selbst Lizenzen ändern will). Es ist keine Schande, einen IT-Rechtsanwalt zu konsultieren. Viele Kanzleien (gerade im IT- und Medienrecht) haben Erfahrung mit Open Source. Kosten dafür sind überschaubar verglichen mit den möglichen Schäden eines Fehlers. Gerade bei Firmenübernahmen, großem Software-Rollout oder wenn ein Streit droht, sollte man Profis ranlassen.

12. Bleibe informiert: Lizenzen entwickeln sich weiter, neue Urteile können kommen, und auch neue Arten von Lizenzen tauchen auf (z.B. zuletzt die Server-Side Public License von MongoDB, die teilweise als „zu aggressiv“ abgelehnt wurde). Für einen Entwickler reicht es, gelegentlich Blogs wie heise Developer, Kanzlei-News oder itmedialaw (😉) zu lesen, um mitzukriegen, ob sich relevante Dinge tun.

Mit diesen Maßnahmen kann man das Risiko drastisch senken. Viele Firmen, vom kleinen Startup bis zum Großkonzern, haben es erfolgreich implementiert: Sie nutzen hunderte Open-Source-Komponenten ohne in rechtliche Fallen zu treten. Es erfordert etwas Disziplin und Wissen, aber die Vorteile der Open-Source-Nutzung – Kostenersparnis, schnelle Entwicklung, kein Rad neu erfinden – rechtfertigen den Aufwand.

Fazit

Open Source ist in der IT-Branche und speziell in der Softwareentwicklung allgegenwärtig und essenziell. Für Game Developer, Plugin-Entwickler und Softwareunternehmen ergeben sich enorme Chancen durch die Verwendung von Open-Source-Komponenten – von beschleunigter Entwicklung bis zu gemeinschaftsgetriebener Innovation. Gleichzeitig dürfen die rechtlichen Rahmenbedingungen nicht ignoriert werden. Urheberrechtlich gesehen bleibt auch Open-Source-Code geschütztes geistiges Eigentum, dessen Nutzung an Bedingungen geknüpft ist. Im IT-Recht und Medienrecht hat sich rund um Open Source ein eigenes Compliance-Feld entwickelt, das heute zum professionellen Arbeiten dazugehört.

Die wichtigsten Erkenntnisse aus praxisnaher Sicht sind:

• Lizenzkompatibilität ist das A und O: Entwickler müssen sicherstellen, dass die genutzten Open-Source-Lizenzen zueinander und zum Lizenzmodell des Gesamtprojekts passen. Stichworte wie GPL-Kompatibilität oder Copyleft-Effekt sind keine theoretischen Konstrukte, sondern können darüber entscheiden, ob ein Produkt rechtssicher auf den Markt gebracht werden kann. Gerade die GPL als starkes Copyleft verlangt Aufmerksamkeit – ihr „viraler“ Effekt kann proprietäre Software „anstecken“. Demgegenüber erlauben permissive Lizenzen meist eine problemlose Integration. Daher ist ein Bewusstsein für Lizenztypen unverzichtbar.

• Rechtsfolgen bei Verstößen sind beherrschbar, aber ernst: Wer die Regeln missachtet, riskiert Unterlassungsansprüche und damit potenziell einen Vertriebsstopp seiner Software. Deutsche Gerichte haben wiederholt bestätigt, dass Open-Source-Lizenzen wirksam sind und Verstöße konsequent als Urheberrechtsverletzung behandeln. Zwar drohen in der Regel keine hohen Schadensersatzzahlungen (da Open Source unentgeltlich ist), jedoch reichen die Unterlassungs- und Auskunftsansprüche aus, um Projekte erheblich zu gefährden. Lizenzverstöße können darüber hinaus zu Vertragsproblemen, Reputationsschäden und Verlust von Vertriebswegen führen. Die Fälle aus der Praxis (von Router-Firmware über Uni-Software bis hin zum WordPress-Theme) verdeutlichen: Prävention ist besser als nachträgliche Heilung.

• Copyleft und proprietäre Entwicklung können koexistieren – mit Planung: Copyleft-Lizenzen wie die GPL schließen kommerzielle Nutzung nicht aus, aber sie erfordern ein entsprechendes Geschäftsmodell (z.B. Service statt Lizenzverkauf) oder eine Architektur, die klare Trennungen wahrt. Für die meisten klassischen proprietären Produkte empfiehlt es sich, Copyleft-Komponenten zu meiden. Sollte ihr Einsatz nötig sein, müssen Entwickler und Entscheider die Konsequenzen genau abwägen. Der „Schrecken“ der GPL liegt vor allem in Unkenntnis begründet – kennt man die genaue Reichweite (wie auch vom OLG Karlsruhe beleuchtet), kann man informierte Entscheidungen treffen. Im Zweifel gibt es meist lizenzfreundlichere Alternativen für nahezu jede Bibliothek.

• Verträge und Policies schaffen Sicherheit im Team und gegenüber Kunden: Es reicht nicht, die Lizenztexte zu kennen; man muss auch intern und vertraglich die Nutzung regeln. Ein Unternehmen im IT-Recht sollte klare vertragliche Abmachungen treffen, wenn es Software entwickeln oder einkaufen lässt. Integrationsklauseln stellen sicher, dass Auftraggeber wissen, woran sie sind, und Prüfpflichten zwingen Lieferanten zur Sorgfalt. Due Diligence bei Übernahmen verhindert, dass „versteckte Verpflichtungen“ mitgekauft werden. All das sind heute Best Practices. Insbesondere Startups oder Indie-Entwickler, die groß rauskommen wollen, sollten frühzeitig diese Professionalität entwickeln – das erhöht auch den Wert ihrer Produkte in den Augen von Investoren und Partnern.

• Zielgruppegerecht handeln: Entwickler von WordPress-Plugins wissen inzwischen meist, dass sie um GPL nicht herumkommen – und arrangieren sich damit. Shopify-App-Entwickler genießen mehr Freiheiten, müssen dafür eigenverantwortlich für Lizenztreue sorgen. Jedes Ökosystem hat seine Spielregeln; wer sie kennt, kann darin problemlos agieren. Wichtig ist, dass auch rechtliche Aspekte Teil der Projektplanung werden – genau wie man Performance oder Security bedenkt, gehört Lizenz-Compliance auf die Checkliste.

• Open Source als Vorteil nutzen, nicht als Risiko scheuen: Am Ende soll nicht der Eindruck bleiben, Open Source sei ein Minenfeld. Im Gegenteil, richtig eingesetzt ist es ein mächtiges Werkzeug. IT-Rechtlich ist vieles mittlerweile geklärt und Handhabbar – es gibt klar definierte Lizenzen und erprobte Vorgehensweisen. Entwickler und Unternehmen, die diese beachten, können sicher und legal von tausenden freien Komponenten profitieren. Gerade im Bereich Softwareentwicklung, Game Development und Plugin-Entwicklung kann man durch Open Source Zeit und Geld sparen und Innovationen teilen. Das erfordert nur, dass man die Verantwortung übernimmt, die mit der Freiheit kommt: also Lizenzbedingungen einzuhalten und die eigene Verwendung transparent zu machen.

Zum Schluss sei gesagt: Open Source und proprietäre Software sind kein Widerspruch, solange man die Grenzlinien respektiert. Mit dem in diesem Artikel vermittelten Wissen – von Urheberrechtsgrundlagen über konkrete Lizenzpflichten bis hin zu vertraglichen Absicherungen – sind Entwickler und Unternehmen gut gerüstet, Open Source rechtskonform und erfolgreich in ihren Projekten einzusetzen. So kann man die Vorteile der Open-Source-Welt nutzen, ohne unangenehme rechtliche Überraschungen zu erleben. In der Schnittmenge von IT-Recht und Technik bleibt Open Source ein spannendes Feld, aber mit der richtigen Vorbereitung verliert es seinen Schrecken und entfaltet sein volles Potenzial zum Nutzen aller Beteiligten.