Open Source rechtssicher nutzen: Lizenzen, Pflichten und Risiken

Open Source ist für viele Unternehmen, Entwickler und Auftraggeber ein praktischer Baustein moderner Softwareprojekte. Bibliotheken, Frameworks, Container-Images, Datenbankkomponenten und ganze Anwendungen lassen sich schnell integrieren, ohne jedes Modul selbst entwickeln zu müssen. Rechtlich bedeutet Open Source jedoch nicht, dass Software frei von Pflichten ist. Die Nutzungsrechte ergeben sich regelmäßig aus einer Lizenz, deren Bedingungen eingehalten werden müssen.

Wer Open-Source-Software nutzt, verändert, weitergibt oder in eigene Produkte einbindet, bewegt sich an der Schnittstelle von Urheberrecht, Vertragsrecht, IT-Vertragsgestaltung, Compliance und Produkthaftung. Die rechtlichen Folgen hängen stark davon ab, welche Lizenz gilt, wie die Software eingesetzt wird und ob eine Weitergabe an Kunden, Nutzer oder verbundene Unternehmen erfolgt. Besonders relevant sind Hinweis-, Offenlegungs-, Lizenztext-, Quellcode- und Copyleft-Pflichten.

Der folgende Beitrag ordnet Open Source juristisch ein, erläutert typische Lizenzmodelle, zeigt Risiken und Fristen auf und gibt praxisnahe Handlungsschritte für Unternehmen, Entwickler und Verantwortliche in Softwareprojekten.

Inhaltsverzeichnis

1. Was bedeutet Open Source rechtlich?
2. Gesetzliche Grundlagen: Urheberrecht, Lizenz und Vertrag
3. Abgrenzung: Open Source, Freeware, Public Domain und proprietäre Software
4. Praxisrelevante Fallkonstellationen bei Unternehmen, Entwicklern und Kunden
5. Typische Open-Source-Lizenzen: permissiv, Copyleft und Netzwerk-Copyleft
6. Risiken, Haftung und typische Fehler im Umgang mit Open Source
7. Fristen, Verjährung und Reaktionszeiten bei Lizenzverstößen
8. Beweisfragen und Dokumentation: Was im Streitfall zählt
9. Praxisschritte: Open Source rechtssicher einsetzen
10. Open Source in Verträgen mit Kunden, Entwicklern und Dienstleistern
11. Besonderheiten bei SaaS, KI, Daten und Sicherheitsupdates
12. FAQ zu Open Source und Recht
13. … und 1 weitere Abschnitte

Was bedeutet Open Source rechtlich?

Open Source bezeichnet Software, deren Quellcode zugänglich ist und deren Nutzung, Bearbeitung und Weitergabe unter bestimmten Bedingungen erlaubt wird. Entscheidend ist nicht allein die technische Verfügbarkeit des Quellcodes, sondern die rechtliche Erlaubnis. Diese Erlaubnis ergibt sich aus einer Open-Source-Lizenz, etwa der MIT License, Apache License 2.0, GNU General Public License (GPL), Lesser GPL (LGPL), Affero GPL (AGPL), BSD License oder Mozilla Public License (MPL).

Rechtlich bleibt Open-Source-Software urheberrechtlich geschützt. Der Urheber oder Rechteinhaber verzichtet grundsätzlich nicht auf seine Rechte, sondern gestattet bestimmte Handlungen unter Bedingungen. Ohne Lizenz wäre etwa das Kopieren, Verändern, öffentliche Zugänglichmachen oder Verbreiten der Software regelmäßig nicht zulässig. Die Open-Source-Lizenz ist daher kein bloßer Hinweis, sondern die Grundlage der erlaubten Nutzung.

In der Praxis wird häufig angenommen, Open Source sei gleichbedeutend mit kostenloser Software. Das ist zu kurz gegriffen. Viele Open-Source-Komponenten können zwar ohne Lizenzgebühr genutzt werden. Dennoch können rechtliche Pflichten entstehen, die wirtschaftlich erheblich sind. Dazu gehören insbesondere die Pflicht zur Beifügung von Lizenztexten, Copyright-Hinweisen, Änderungsvermerken oder – bei bestimmten Copyleft-Lizenzen – die Pflicht, Quellcode bereitzustellen.

Für Unternehmen ist zusätzlich relevant, ob Open Source nur intern verwendet oder zusammen mit einem Produkt an Kunden weitergegeben wird. Eine rein interne Nutzung löst in vielen Fällen weniger Pflichten aus als eine Distribution. Bei Cloud- oder SaaS-Modellen kann wiederum die AGPL besondere Bedeutung erlangen, weil sie Pflichten schon bei netzwerkbasierter Nutzung auslösen kann. Die genaue Bewertung hängt deshalb nicht nur von der Lizenz, sondern auch vom technischen und geschäftlichen Einsatzmodell ab.

Gesetzliche Grundlagen: Urheberrecht, Lizenz und Vertrag

Die wichtigste gesetzliche Grundlage ist das Urheberrechtsgesetz. Software ist in Deutschland als Computerprogramm urheberrechtlich geschützt, insbesondere nach §§ 69a ff. UrhG. Geschützt ist nicht jede Idee oder Funktionalität als solche, sondern die konkrete Ausdrucksform des Programms, also insbesondere der Quellcode und Objektcode, soweit die gesetzlichen Voraussetzungen vorliegen. Daneben können Dokumentation, Benutzeroberflächen, Datenbanken, Texte oder Grafiken eigenständig geschützt sein.

Wer fremde Software vervielfältigt, bearbeitet, verbreitet oder öffentlich zugänglich macht, benötigt grundsätzlich eine entsprechende Nutzungsrechtseinräumung. Bei Open Source erfolgt diese Rechtegewährung typischerweise durch eine Standardlizenz. Diese Lizenzen werden häufig weltweit und massenhaft verwendet. Dennoch sind sie im deutschen Rechtsumfeld auszulegen. Maßgeblich ist unter anderem, welche Rechte tatsächlich eingeräumt werden, welche Bedingungen an die Einräumung geknüpft sind und welche Folgen ein Verstoß hat.

Juristisch wird diskutiert, ob Open-Source-Lizenzen stets als Vertrag oder primär als einseitige Rechtegewährung mit Bedingungen zu verstehen sind. Für die Praxis ist diese dogmatische Einordnung häufig weniger entscheidend als die Frage, ob die Lizenzbedingungen eingehalten wurden. Werden Lizenzpflichten verletzt, kann die Nutzungsberechtigung entfallen oder gar nicht wirksam greifen. Dann drohen urheberrechtliche Ansprüche wie Unterlassung, Auskunft, Beseitigung, Rückruf, Schadensersatz oder Erstattung von Abmahnkosten.

Neben dem Urheberrecht sind weitere Rechtsgebiete relevant. Im B2B-Verhältnis spielen Softwareentwicklungsverträge, IT-Projektverträge, Gewährleistung, Haftungsbegrenzungen, Freistellungsklauseln und Compliance-Zusicherungen eine erhebliche Rolle. Bei Softwareprodukten mit Sicherheitsbezug können IT-Sicherheitsanforderungen, Datenschutzrecht, branchenspezifische Regulierung und künftig auch europäische Vorgaben zur Cyberresilienz hinzukommen. Open Source ist deshalb nicht isoliert zu prüfen, sondern als Bestandteil der gesamten Liefer- und Vertragskette.

Zu beachten ist außerdem, dass Open-Source-Lizenzen häufig Haftungs- und Gewährleistungsausschlüsse enthalten. Diese wirken aber nicht automatisch in jedem Verhältnis und nicht zwingend gegenüber jedem Vertragspartner. Ein Unternehmen, das Open-Source-Komponenten in ein eigenes Produkt integriert und dieses Produkt verkauft oder bereitstellt, kann gegenüber seinen Kunden trotzdem für Mängel, Rechtsmängel oder zugesicherte Eigenschaften verantwortlich sein. Die Lizenz des ursprünglichen Open-Source-Projekts ersetzt daher nicht die eigene Vertragsgestaltung.

Abgrenzung: Open Source, Freeware, Public Domain und proprietäre Software

Eine rechtssichere Bewertung beginnt mit der Abgrenzung zu ähnlichen Begriffen. Gerade in technischen Teams werden Bezeichnungen wie Open Source, Freeware, freie Software, Community Edition, Public Domain oder source-available teilweise austauschbar verwendet. Rechtlich kann diese Vermischung zu Fehlentscheidungen führen. Nicht jede kostenlos herunterladbare Software darf in ein kommerzielles Produkt integriert werden. Nicht jeder öffentlich sichtbare Quellcode ist Open Source. Und nicht jede Open-Source-Lizenz erlaubt denselben Einsatz.

Die folgende Übersicht zeigt typische Unterschiede. Sie ersetzt keine Lizenzprüfung, verdeutlicht aber, warum ein bloßer Blick auf den Downloadpreis oder das Git-Repository nicht genügt. Entscheidend sind stets Lizenztext, Rechteinhaberschaft, Einsatzart und die konkrete Verknüpfung mit eigener Software.

Die Abgrenzung ist besonders wichtig, wenn Software in Produkte, Apps, Maschinensteuerungen, Webplattformen oder SaaS-Dienste eingebettet wird. Bei Open Source darf häufig mehr als bei proprietärer Software, aber nicht bedingungslos. Bei Freeware darf oft weniger, obwohl keine Lizenzgebühr anfällt. Bei source-available-Modellen ist der Quellcode zwar sichtbar, die Lizenz kann aber kommerzielle Nutzung ausschließen oder nur bestimmte Zwecke erlauben.

Auch der Begriff freie Software ist nicht vollständig deckungsgleich mit Open Source, auch wenn es große Schnittmengen gibt. Während freie Software stärker die Freiheitsrechte der Nutzer betont, wird Open Source häufig pragmatischer über Entwicklungsmodell und Lizenzkriterien beschrieben. Für die juristische Prüfung ist diese ideelle Unterscheidung meist nachrangig. Maßgeblich bleibt der konkrete Lizenztext und seine Wirkung im vorgesehenen Einsatz.

Praxisrelevante Fallkonstellationen bei Unternehmen, Entwicklern und Kunden

Open Source wird in sehr unterschiedlichen Situationen relevant. Eine typische Konstellation betrifft Unternehmen, die ein Softwareprodukt entwickeln und dafür Drittkomponenten verwenden. Entwickler greifen auf Paketmanager wie npm, Maven, PyPI, NuGet, Composer oder Cargo zurück. Dabei werden nicht nur direkt ausgewählte Pakete eingebunden, sondern häufig auch zahlreiche transitive Abhängigkeiten. Jede dieser Komponenten kann eine eigene Lizenz haben. Wird später ein Produkt ausgeliefert, können daraus Hinweis- und Offenlegungspflichten entstehen.

Ein weiteres Beispiel ist die Nutzung von Open-Source-Komponenten in Embedded-Systemen, etwa in Maschinen, IoT-Geräten, Fahrzeugkomponenten, Routern oder Medizintechnik. Hier wird Software zusammen mit Hardware vertrieben. Wird eine GPL-lizenzierte Komponente genutzt, kann die Pflicht zur Bereitstellung des korrespondierenden Quellcodes entstehen. Je nach Architektur kann umstritten sein, ob nur die Open-Source-Komponente oder auch eigene Anpassungen und verbundene Module betroffen sind. Eine pauschale Antwort ist kaum möglich, weil technische Kopplung, Lizenzversion und Distributionsmodell entscheidend sind.

Auch im Agentur- und Projektgeschäft entstehen typische Streitfälle. Ein Dienstleister entwickelt für einen Kunden eine Plattform und nutzt dabei Open-Source-Frameworks. Später verlangt der Kunde eine Garantie, dass keine Copyleft-Pflichten bestehen oder dass sämtliche Rechte uneingeschränkt übertragen wurden. Der Dienstleister kann dies aber nur zusichern, wenn zuvor eine ordentliche Komponentenprüfung durchgeführt wurde. Ohne Software Bill of Materials, Lizenzliste und Dokumentation bleibt unklar, welche Drittsoftware tatsächlich enthalten ist.

Bei SaaS- und Cloud-Angeboten ist die Lage differenziert. Viele Open-Source-Lizenzen knüpfen zentrale Pflichten an Verbreitung oder Weitergabe der Software. Wird Software lediglich serverseitig betrieben, ohne dass der Kunde eine Kopie erhält, greifen manche Pflichten nicht in gleicher Weise. Allerdings kann die AGPL gerade netzwerkbasierte Interaktion erfassen und eine Quellcodebereitstellung für modifizierte Versionen verlangen. Ob dies im Einzelfall zutrifft, hängt von der konkreten Nutzung und Lizenzfassung ab.

Konflikte entstehen außerdem bei Unternehmenskäufen, Investorenprüfungen und Produktzertifizierungen. In einer technischen Due Diligence wird geprüft, ob die eingesetzte Software rechtlich sauber dokumentiert ist. Fehlen Lizenznachweise, Copyright-Hinweise oder Freigabeprozesse, kann dies zu Nachfragen, Kaufpreisanpassungen, Garantiekatalogen oder Nachbesserungspflichten führen. Open Source ist deshalb nicht nur ein Entwicklungsthema, sondern auch ein Corporate-, Compliance- und Haftungsthema.

Typische Open-Source-Lizenzen: permissiv, Copyleft und Netzwerk-Copyleft

Open-Source-Lizenzen unterscheiden sich erheblich. Für die Praxis ist vor allem wichtig, ob eine Lizenz permissiv ausgestaltet ist oder Copyleft-Pflichten enthält. Permissive Lizenzen erlauben typischerweise eine breite Nutzung, Bearbeitung und Weitergabe, auch innerhalb proprietärer Produkte. Dennoch müssen meist Copyright-Hinweise, Lizenztexte und Haftungsausschlüsse beibehalten werden. Beispiele sind MIT, BSD oder Apache 2.0. Die Apache License enthält zusätzlich Regelungen zu Patentrechten, die für Unternehmen bedeutsam sein können.

Copyleft-Lizenzen verfolgen ein anderes Konzept. Sie erlauben Nutzung und Veränderung, verlangen aber unter bestimmten Voraussetzungen, dass abgeleitete Werke wiederum unter denselben Lizenzbedingungen weitergegeben werden. Die GPL ist das bekannteste Beispiel. Wird GPL-Code in ein eigenes Produkt eingebunden und dieses Produkt verteilt, kann die Pflicht entstehen, den Quellcode des abgeleiteten Werks unter GPL bereitzustellen. Ob eine eigene Software als abgeleitetes Werk gilt, ist technisch und rechtlich im Einzelfall zu bewerten.

Die LGPL ist im Vergleich zur GPL häufig weniger streng, insbesondere bei der Nutzung von Bibliotheken. Sie kann ermöglichen, proprietäre Software mit einer LGPL-Bibliothek zu verlinken, sofern bestimmte Bedingungen eingehalten werden. Dazu können etwa Austauschbarkeit der Bibliothek, Bereitstellung von Änderungen an der Bibliothek und Lizenzhinweise gehören. Auch hier reicht eine grobe Einordnung nicht aus, weil statisches oder dynamisches Linking, Modifikationen und Auslieferungsform unterschiedlich zu bewerten sein können.

Die AGPL erweitert das Copyleft-Prinzip auf bestimmte netzwerkbasierte Nutzungen. Sie ist vor allem bei Webanwendungen, Plattformen und SaaS-Angeboten relevant. Während klassische GPL-Pflichten häufig an die Verteilung von Kopien anknüpfen, kann die AGPL Pflichten auslösen, wenn Nutzer über ein Netzwerk mit einer modifizierten Programmversion interagieren. Für Unternehmen mit Cloudprodukten ist diese Lizenz daher besonders prüfungsbedürftig.

Daneben gibt es projekt- und anwendungsspezifische Lizenzmodelle, duale Lizenzierungen und Mischformen. Manche Anbieter stellen eine Community-Version unter Open Source bereit, bieten aber für kommerzielle Nutzung, zusätzliche Funktionen oder Haftungszusagen proprietäre Lizenzen an. Für die Rechtsabteilung oder Projektverantwortliche ist entscheidend, nicht allein auf den Namen der Lizenz zu achten, sondern die konkreten Komponenten, Versionen, Abhängigkeiten und Nutzungsformen zu erfassen.

Risiken, Haftung und typische Fehler im Umgang mit Open Source

Die rechtlichen Risiken bei Open Source entstehen selten durch die bloße Verwendung einer bekannten Bibliothek. Kritisch wird es, wenn Lizenzpflichten unbekannt bleiben, Komponenten ohne Prüfung weitergegeben werden oder vertragliche Zusagen gemacht werden, die technisch nicht abgesichert sind. In Unternehmen ist zudem problematisch, wenn einzelne Entwickler Entscheidungen treffen, die später Auswirkungen auf Vertrieb, Kundenverträge, Investorenprüfungen oder Produkthaftung haben.

Bei einem Lizenzverstoß kommen urheberrechtliche Ansprüche in Betracht. Rechteinhaber können unter Umständen Unterlassung verlangen, Auskunft über Art und Umfang der Nutzung fordern, Schadensersatz geltend machen oder die Erstattung erforderlicher Rechtsverfolgungskosten verlangen. Daneben kann die Lizenzverletzung zu vertraglichen Problemen mit Kunden führen. Wenn ein Unternehmen zugesichert hat, dass ein Produkt frei von bestimmten Open-Source-Pflichten ist, kann eine unerkannte Copyleft-Komponente einen Rechtsmangel oder eine Vertragsverletzung begründen.

Haftungsfragen sind einzelfallabhängig. Nicht jeder formale Fehler führt automatisch zu einem hohen Schaden. In vielen Fällen lassen sich fehlende Lizenztexte, Notices oder Quellcodeangebote nachträglich korrigieren. Allerdings kann eine späte Korrektur nicht immer verhindern, dass bereits Ansprüche entstanden sind. Bei Produkten, die in großer Stückzahl vertrieben wurden, international ausgeliefert sind oder sicherheitskritische Funktionen enthalten, kann die Bereinigung organisatorisch und wirtschaftlich anspruchsvoll werden.

Typische Fehler sind insbesondere:

• Open Source wird wegen fehlender Lizenzgebühr als rechtlich frei von Pflichten behandelt.
• Lizenztexte und Copyright-Hinweise werden beim Build-Prozess entfernt oder nicht ausgeliefert.
• Transitive Abhängigkeiten aus Paketmanagern werden nicht erfasst.
• GPL-, LGPL- oder AGPL-Komponenten werden ohne Prüfung in proprietäre Produkte integriert.
• Entwickler kopieren Code aus Repositories, Foren oder KI-gestützten Vorschlägen ohne Herkunftsprüfung.
• Kundenverträge enthalten pauschale Zusicherungen zur Rechtefreiheit, die intern nicht belegbar sind.
• Bei M&A-Prüfungen fehlen Lizenzlisten, Komponentenverzeichnisse und Freigabeentscheidungen.
• Sicherheitsupdates werden eingespielt, ohne Lizenzänderungen oder neue Abhängigkeiten zu prüfen.

Ein weiteres Risiko liegt in der Lieferkette. Software wird heute selten vollständig intern entwickelt. Externe Dienstleister, Nearshore-Teams, freie Entwickler, Systemintegratoren und Cloudanbieter können Komponenten beisteuern. Wenn Verträge keine klaren Vorgaben zu Open Source, Dokumentation, Freistellung und Nachweispflichten enthalten, ist später schwer festzustellen, wer für eine problematische Komponente verantwortlich ist. Verantwortlichkeit und Beweisbarkeit fallen dann auseinander.

Schließlich darf der technische Sicherheitsaspekt nicht ausgeblendet werden. Open-Source-Komponenten können bekannte Schwachstellen enthalten. Das ist kein spezifisches Open-Source-Problem, wird aber durch große Abhängigkeitsbäume verstärkt. Rechtlich kann relevant werden, ob ein Unternehmen angemessene Prozesse zur Schwachstellenüberwachung, Aktualisierung und Dokumentation eingerichtet hat. Je nach Produkt und Branche können daraus vertragliche, regulatorische oder haftungsrechtliche Anforderungen entstehen.

Fristen, Verjährung und Reaktionszeiten bei Lizenzverstößen

Bei Open-Source-Verstößen gibt es nicht die eine einheitliche Frist. Zu unterscheiden sind vertragliche Reaktionsfristen, gesetzliche Verjährungsfristen, Fristen aus Abmahnungen und praktische Zeitfenster zur Risikobegrenzung. Wer eine Abmahnung oder Aufforderung wegen eines Lizenzverstoßes erhält, sollte die dort gesetzte Frist ernst nehmen. Solche Fristen sind häufig kurz. Ob sie angemessen sind, hängt vom Umfang des Vorwurfs, der Komplexität der Prüfung und den Umständen des Einzelfalls ab. Ignorieren ist regelmäßig keine gute Option, weil gerichtliche Schritte folgen können.

Urheberrechtliche Ansprüche unterliegen grundsätzlich der Verjährung. Für viele Ansprüche gilt die regelmäßige Verjährungsfrist von drei Jahren, beginnend mit dem Schluss des Jahres, in dem der Anspruch entstanden ist und der Rechteinhaber von den anspruchsbegründenden Umständen sowie der Person des Schuldners Kenntnis erlangt oder ohne grobe Fahrlässigkeit hätte erlangen müssen. Daneben können besondere Regeln, etwa zur Herausgabe des Erlangten, längere Zeiträume betreffen. Im Urheberrecht sind insbesondere § 102 UrhG und die Verweisung auf bürgerlich-rechtliche Vorschriften zu beachten. Die genaue Berechnung ist komplex und hängt von Anspruchsart, Kenntnis und Nutzungshandlungen ab.

Für Unterlassungsansprüche ist außerdem zu berücksichtigen, dass fortdauernde oder wiederholte Nutzungshandlungen neue Relevanz entfalten können. Selbst wenn ältere Ansprüche teilweise verjährt sein sollten, kann ein aktuelles Angebot, ein weiterer Download, eine neue Auslieferung oder eine fortgesetzte öffentliche Bereitstellung erneut angegriffen werden. Verjährung ist daher kein Ersatz für eine technische und rechtliche Bereinigung.

Vertragliche Fristen spielen vor allem in Kunden- und Lieferantenverhältnissen eine Rolle. Verträge können Auditfristen, Mitteilungsfristen, Mängelrügeobliegenheiten, Nachbesserungsfristen, Eskalationsverfahren oder Freistellungsfristen enthalten. Wird ein Open-Source-Problem in der Lieferkette entdeckt, sollte geprüft werden, ob der eigene Vertrag eine unverzügliche Benachrichtigung verlangt oder ob Ansprüche gegen Dienstleister nur innerhalb bestimmter Fristen geltend gemacht werden können.

Praktisch empfiehlt sich eine schnelle Erstbewertung innerhalb weniger Tage, wenn eine konkrete Beanstandung vorliegt. Dabei sollte nicht vorschnell eine Unterlassungserklärung abgegeben werden. Eine zu weit formulierte Erklärung kann langfristige Vertragsstrafenrisiken auslösen. Andererseits kann eine berechtigte Beanstandung nicht einfach ausgesessen werden. Sinnvoll ist eine strukturierte Prüfung: betroffene Versionen identifizieren, Lizenzlage klären, Distribution stoppen oder kontrollieren, Korrekturmaßnahmen planen und Kommunikation rechtlich abstimmen.

Beweisfragen und Dokumentation: Was im Streitfall zählt

In Streitfällen entscheidet nicht nur, was technisch geschehen ist, sondern auch, was nachweisbar ist. Unternehmen können häufig erklären, welche Open-Source-Komponenten sie nach eigener Einschätzung nutzen. Schwieriger ist der belastbare Nachweis, welche Version zu welchem Zeitpunkt in welchem Produktstand enthalten war, welche Lizenz galt, welche Hinweise ausgeliefert wurden und wer eine Freigabe erteilt hat. Eine saubere Dokumentation ist deshalb ein zentrales Element der Open-Source-Compliance.

Beweisprobleme entstehen besonders bei älteren Releases, schnelllebigen DevOps-Prozessen und nachträglich geänderten Repositories. Lizenztexte können sich ändern, Pakete können ausgetauscht werden, transitive Abhängigkeiten können durch Updates hinzukommen. Wenn Build-Artefakte, Release-Notes, SBOM-Dateien und Lizenzberichte fehlen, wird die spätere Rekonstruktion aufwendig. Für Unternehmen kann dies bei Kundenanfragen, Audits oder gerichtlichen Auseinandersetzungen nachteilig sein.

Hilfreich sind insbesondere folgende Nachweise:

• Software Bill of Materials (SBOM) mit Komponenten, Versionen, Hashwerten und Herkunft.
• Lizenzliste mit Zuordnung jeder Komponente zur jeweiligen Lizenzfassung.
• Kopien der maßgeblichen Lizenztexte und Copyright-Hinweise zum Release-Zeitpunkt.
• Freigabeentscheidungen, etwa durch Rechtsabteilung, Open-Source-Board oder Projektleitung.
• Build-Protokolle, Dependency-Lockfiles und Container-Image-Nachweise.
• Dokumentation ausgelieferter Notices, About-Dialoge, Readme-Dateien oder Begleitunterlagen.
• Nachweise über bereitgestellten Quellcode, Downloadlinks, Archivstände und Angebotsfristen.
• Kommunikation mit Dienstleistern, Kunden oder Rechteinhabern über Lizenzfragen.

Die Dokumentation sollte nicht erst bei einem Konflikt beginnen. Gerade in agilen Projekten ist es sinnvoll, Lizenzinformationen automatisiert zu erfassen und in den Release-Prozess einzubinden. Tools zur Software Composition Analysis können unterstützen, ersetzen aber keine rechtliche Bewertung. Sie erkennen nicht jede Lizenz zuverlässig, bewerten technische Kopplungen nur begrenzt und können Sonderfälle wie Dual Licensing, individuelle Contributor Agreements oder projektspezifische Ausnahmen übersehen.

Für den Streitfall ist außerdem wichtig, zwischen Tatsachendokumentation und rechtlicher Bewertung zu unterscheiden. Entwickler können meist am besten erklären, wie eine Komponente eingebunden wurde. Die rechtliche Bewertung, ob daraus Copyleft-Pflichten folgen oder ob eine Lizenzbedingung verletzt wurde, sollte gesondert erfolgen. Werden beide Ebenen vermischt, entstehen unklare Aussagen, die später missverständlich verwendet werden können.

Praxisschritte: Open Source rechtssicher einsetzen

Ein rechtssicherer Umgang mit Open Source setzt keinen übermäßig bürokratischen Prozess voraus. Erforderlich ist aber eine klare Zuständigkeit und ein nachvollziehbares Verfahren. Je größer das Produkt, je stärker die Distribution und je sensibler die Kundenbeziehungen sind, desto wichtiger werden dokumentierte Freigaben. Für kleine interne Tools genügt häufig ein schlankerer Prozess als für ein kommerziell vertriebenes Softwareprodukt oder ein Embedded-System.

Die folgenden Schritte haben sich in der Praxis als Orientierung bewährt. Sie müssen an Unternehmensgröße, Branche, Entwicklungsmodell und Risikoprofil angepasst werden:

• Komponenten erfassen: Alle direkten und transitiven Open-Source-Abhängigkeiten je Produkt, Version und Release dokumentieren.
• Lizenztexte sichern: Maßgebliche Lizenzfassungen zum Zeitpunkt der Nutzung archivieren, nicht nur auf externe Links verweisen.
• Einsatzart bestimmen: Prüfen, ob die Software intern genutzt, an Kunden verteilt, in Hardware eingebettet oder als SaaS betrieben wird.
• Copyleft-Risiken bewerten: GPL, LGPL, AGPL, MPL und ähnliche Lizenzen anhand technischer Kopplung und Auslieferungsform gesondert prüfen.
• Notice-Pflichten umsetzen: Copyright-Hinweise, Lizenztexte, Änderungsvermerke und Haftungsausschlüsse in Produktdokumentation oder UI einbinden.
• Quellcodepflichten planen: Bei einschlägigen Lizenzen Quellcode, Build-Skripte und Angebote fristgerecht bereitstellen und archivieren.
• Freigaben dokumentieren: Entscheidungen mit Datum, Verantwortlichem, Produktversion und Begründung festhalten.
• Verträge anpassen: Kunden- und Dienstleisterverträge auf Open-Source-Klauseln, Zusicherungen, Freistellungen und Nachweispflichten prüfen.
• Updates kontrollieren: Lizenz- und Sicherheitsprüfung bei Versionswechseln wiederholen, insbesondere vor Major Releases.
• Reaktionsplan erstellen: Zuständigkeiten für Abmahnungen, Kundenanfragen, Schwachstellenmeldungen und Audit-Anforderungen festlegen.
• Fristen überwachen: Abmahnfristen, vertragliche Mitteilungsfristen und Quellcode-Bereitstellungszeiträume zentral erfassen.
• Nachweise releasebezogen archivieren: SBOM, Lizenzbericht, ausgelieferte Notices und Build-Artefakte für jede veröffentlichte Version speichern.

Bei bestehenden Produkten beginnt die Prüfung häufig mit einer Bestandsaufnahme. Dabei sollten nicht nur aktuelle Repositories betrachtet werden. Relevant sind auch ältere Release-Zweige, ausgelieferte Installationspakete, Container, Firmware-Versionen, mobile Apps und Kundensonderstände. Gerade Kundensonderanpassungen können Komponenten enthalten, die im Hauptprodukt nicht mehr sichtbar sind.

Wenn ein konkreter Verstoß vermutet wird, sollte die technische Verbreitung kontrolliert werden. Dazu kann gehören, Downloads vorübergehend zu stoppen, betroffene Images zurückzuziehen, Vertrieb und Support zu informieren oder eine korrigierte Version vorzubereiten. Solche Maßnahmen sollten verhältnismäßig sein und rechtlich abgestimmt werden, weil sie Kundenpflichten, Service Level Agreements und Kommunikationsrisiken berühren können.

Für Unternehmen mit regelmäßiger Softwareentwicklung ist eine Open-Source-Policy sinnvoll. Sie sollte verständlich formuliert sein und Entwicklern praktikable Leitplanken geben. Eine Policy, die jede Nutzung genehmigungspflichtig macht, aber keine schnelle Freigabe ermöglicht, wird im Alltag oft umgangen. Besser ist eine risikobasierte Einteilung: unkritische permissive Lizenzen, prüfungsbedürftige Copyleft-Lizenzen, gesperrte oder nur mit Sonderfreigabe zulässige Komponenten.

Open Source in Verträgen mit Kunden, Entwicklern und Dienstleistern

Open Source sollte in IT-Verträgen ausdrücklich geregelt werden. Ohne klare Vereinbarungen entstehen häufig Missverständnisse. Auftraggeber erwarten manchmal eine ausschließliche Rechteübertragung an der gesamten Software. Das ist bei Open-Source-Komponenten nicht möglich, weil diese nur nach den jeweiligen Lizenzbedingungen genutzt werden dürfen. Auftragnehmer wiederum gehen teilweise davon aus, dass der Einsatz gängiger Frameworks selbstverständlich erlaubt ist. Beide Sichtweisen können berechtigt erscheinen, führen aber ohne transparente Regelung zu Konflikten.

In Entwicklungsverträgen sollte festgelegt werden, ob und in welchem Umfang Open Source eingesetzt werden darf. Sinnvoll sind Vorgaben zu zulässigen Lizenzkategorien, Informationspflichten, Freigabeprozessen und Dokumentationsformaten. Bei kritischen Produkten kann vereinbart werden, dass Copyleft-Komponenten nur nach vorheriger Zustimmung verwendet werden dürfen. Zugleich sollte vermieden werden, jede unbedeutende Entwicklungsabhängigkeit zum Vertragsverstoß zu machen. Eine differenzierte Klausel ist meist praxistauglicher als ein pauschales Verbot.

Für Auftraggeber ist wichtig, dass sie am Ende nicht nur lauffähige Software erhalten, sondern auch die zugehörigen Lizenzinformationen. Dazu gehören Lizenzliste, Notice-Dateien, Quellcodeangebote, bekannte Pflichten und Hinweise auf Komponenten, die bei Weitergabe besondere Anforderungen auslösen. Diese Unterlagen sollten als Abnahmegegenstand oder Liefergegenstand beschrieben werden. Andernfalls kann später streitig sein, ob die Dokumentation geschuldet war.

Für Auftragnehmer und Dienstleister sind realistische Zusicherungen bedeutsam. Eine Garantie, dass keinerlei Open Source enthalten ist, kann riskant sein, wenn tatsächlich Standardbibliotheken, Build-Tools oder Frameworks verwendet werden. Ebenso problematisch ist die Zusicherung unbeschränkter Rechteübertragung an Codebestandteilen, die unter Dritt-Lizenzen stehen. Sinnvoller sind präzise Erklärungen: welche Komponenten enthalten sind, unter welchen Lizenzen sie stehen und welche Pflichten daraus folgen.

Auch Freistellungsklauseln verdienen Aufmerksamkeit. Auftraggeber möchten sich gegen Ansprüche Dritter absichern. Auftragnehmer sollten prüfen, ob eine Freistellung auf selbst zu vertretende Verstöße begrenzt ist und ob der Auftraggeber eigene Mitwirkungspflichten einhält. Wird Open Source nach Übergabe durch den Auftraggeber verändert, aktualisiert oder in anderer Weise vertrieben, sollte die Verantwortlichkeit klar abgegrenzt sein.

Besonderheiten bei SaaS, KI, Daten und Sicherheitsupdates

Moderne Softwareprojekte verbinden Open Source häufig mit SaaS-Angeboten, KI-Komponenten, Trainingsdaten, APIs und automatisierten Updateprozessen. Dadurch entstehen zusätzliche Prüfungsfragen. Bei SaaS ist zunächst zu klären, ob Kunden eine Kopie der Software erhalten oder lediglich über ein Netzwerk auf Funktionen zugreifen. Viele klassische Lizenzpflichten knüpfen an Verbreitung an. Dennoch können bestimmte Lizenzen, insbesondere AGPL, gerade den Netzwerkzugriff erfassen. Wer AGPL-Komponenten serverseitig modifiziert, sollte genau prüfen, ob Quellcodepflichten gegenüber Nutzern entstehen.

Bei KI-gestützter Entwicklung stellt sich die Frage nach der Herkunft von Codevorschlägen. Wenn Entwickler Codefragmente übernehmen, ohne zu wissen, ob diese aus lizenzpflichtigen Projekten stammen, kann eine spätere Rechteklärung schwierig sein. Nicht jeder kurze Vorschlag ist urheberrechtlich relevant, und nicht jede Ähnlichkeit begründet einen Verstoß. Gleichwohl sollten Unternehmen Regeln für die Nutzung von Coding-Assistenten festlegen, insbesondere bei umfangreichen Codeübernahmen, sicherheitskritischen Modulen und proprietären Kernbestandteilen.

Daten und Modelle sind gesondert zu betrachten. Open-Source-Softwarelizenzen regeln nicht automatisch die Rechte an Datenbanken, Trainingsdaten, Modellgewichten, Dokumentationen oder Marken. Für diese Inhalte können eigene Lizenzen gelten. Creative-Commons-Lizenzen werden häufig für Texte, Bilder oder Daten verwendet, sind aber nicht ohne Weiteres passend für Softwarecode. Umgekehrt sagt eine Open-Source-Lizenz des Codes nicht zwingend etwas darüber aus, ob ein Markenname oder ein Logo kommerziell verwendet werden darf.

Sicherheitsupdates können lizenzrechtliche Auswirkungen haben. Ein Update kann neue Abhängigkeiten einführen, Lizenzbedingungen ändern oder aus einer permissiven Komponente eine Copyleft-nahe Abhängigkeit machen. Deshalb sollte die Lizenzprüfung nicht nur beim ersten Einbau erfolgen. Besonders bei automatisierten Dependency-Updates ist ein Kontrollmechanismus sinnvoll. Andernfalls kann ein zuvor unkritisches Produkt durch ein Update neue Pflichten auslösen.

In regulierten Branchen kommt hinzu, dass Nachvollziehbarkeit und Schwachstellenmanagement rechtlich an Bedeutung gewinnen. Hersteller, Betreiber und Anbieter müssen je nach Produkt und Rechtsrahmen belegen können, welche Komponenten enthalten sind und wie sie mit bekannten Sicherheitslücken umgehen. Open-Source-Compliance und Security-Compliance sollten daher nicht getrennt organisiert werden. Eine SBOM kann beide Bereiche verbinden, ersetzt aber weder Sicherheitsbewertung noch Lizenzprüfung.

FAQ zu Open Source und Recht

Fazit: Open Source nutzen, ohne Lizenzpflichten zu übersehen

Open Source kann Entwicklung beschleunigen und technisch hochwertige Lösungen ermöglichen. Rechtlich bleibt jedoch entscheidend, dass die jeweilige Lizenz verstanden und eingehalten wird. Vorrangig sollten Unternehmen wissen, welche Komponenten sie verwenden, unter welchen Lizenzen diese stehen und ob eine Weitergabe, SaaS-Nutzung oder Einbindung in proprietäre Produkte erfolgt. Danach lassen sich Notice-Pflichten, Copyleft-Risiken, Quellcodeangebote und vertragliche Zusicherungen belastbar bewerten.

Die wichtigsten nächsten Schritte sind eine vollständige Komponentenübersicht, eine risikobasierte Lizenzprüfung, eine saubere Dokumentation je Release und klare Regelungen in Kunden- und Dienstleisterverträgen. Bei Abmahnungen, Due-Diligence-Prüfungen oder kritischen Copyleft-Konstellationen sollte vorschnelles Handeln vermieden und die technische Lage zuerst gesichert werden. Welche Pflichten tatsächlich bestehen, hängt stets vom konkreten Lizenztext, der Softwarearchitektur und dem Einsatzmodell ab.