Open-Source-Lizenzen im Unternehmen

Ein Entwicklungsteam übernimmt eine Bibliothek aus einem öffentlichen Repository, weil sie ein dringendes Problem schnell löst. Die Komponente funktioniert, der Release steht kurz bevor. Erst bei einer Kundenprüfung fällt auf: Die Bibliothek steht unter einer Copyleft Lizenz. Nun ist unklar, ob Quellcode offengelegt werden muss, ob die Komponente ersetzt werden kann und wer die damalige Auswahl freigegeben hat. Solche Situationen entstehen selten aus Nachlässigkeit. Meist fehlt ein verlässlicher Prozess für Open Source Lizenzen.

Open Source Software ist im Unternehmen längst Teil fast jeder Anwendung, Infrastruktur und Entwicklungsumgebung. Sie kann Kosten senken, Entwicklungszeit verkürzen und technische Qualität verbessern. „Open Source“ bedeutet aber nicht „ohne rechtliche Bedingungen“. Jede Komponente wird unter einer konkreten Lizenz genutzt. Diese Lizenz bestimmt, was du tun darfst und welche Pflichten du dabei erfüllen musst.

Warum die Lizenz wichtiger ist als das Repository

Eine Komponente kann frei zugänglich sein und trotzdem weitreichende Nutzungsbedingungen enthalten. Entscheidend ist daher nicht, ob der Quellcode öffentlich verfügbar ist, sondern welche Lizenz für die verwendete Version gilt.

Bei jeder Prüfung solltest du zunächst drei Fragen trennen:

• Welche konkrete Komponente wird verwendet, einschließlich Version und Bezugsquelle?
• Unter welcher Lizenz steht genau diese Version?
• Wie wird die Komponente technisch und wirtschaftlich eingesetzt?

Die letzte Frage wird häufig unterschätzt. Eine Bibliothek, die nur intern für Tests genutzt wird, ist anders zu bewerten als dieselbe Bibliothek in einem Produkt, das an Kunden ausgeliefert wird. Ebenso kann es relevant sein, ob der Code lediglich neben der eigenen Software läuft, dynamisch eingebunden wird, statisch integriert ist oder verändert wurde.

Auch mehrere Lizenzen pro Komponente sind möglich. Manche Projekte bieten eine Auswahl an Lizenzen an. Andere enthalten Abhängigkeiten mit eigenen Lizenzbedingungen. Eine Prüfung darf deshalb nicht bei der Lizenz der obersten Komponente enden.

Permissive Lizenzen: Weitgehende Freiheit mit Grundpflichten

Permissive Lizenzen erlauben typischerweise eine breite Nutzung. Du darfst Software meist verwenden, kopieren, verändern und in eigene Produkte integrieren, auch in proprietäre Software. Häufig verwendete Beispiele sind die MIT Lizenz, BSD Lizenzen oder die Apache Lizenz.

Die Freiheiten sind praktisch, aber nicht bedingungslos. Typische Pflichten sind:

• Lizenztexte und Copyright Hinweise müssen erhalten bleiben.
• Hinweise auf Haftungsausschlüsse müssen mitgeliefert werden.
• Veränderungen oder Urhebervermerke dürfen nicht unzulässig entfernt werden.
• Bei einzelnen Lizenzen können besondere Patentregelungen oder Hinweise zu Marken relevant sein.

Bei permissiven Lizenzen liegt der Aufwand daher oft weniger in der Frage, ob du deine eigene Software offenlegen musst. Wichtiger ist ein sauberer Nachweis, dass Lizenztexte, Notices und Copyright Angaben korrekt in die Auslieferung aufgenommen wurden.

Gerade bei Produkten mit vielen Drittkomponenten empfiehlt sich eine zentrale Datei mit Lizenzhinweisen. Sie sollte automatisch oder kontrolliert aus dem Komponentenverzeichnis erzeugt werden und in der ausgelieferten Software leicht auffindbar sein. Bei einer Webanwendung kann das beispielsweise über einen Bereich „Open Source Hinweise“ erfolgen, bei installierbarer Software in der Dokumentation oder im Installationspaket.

Copyleft: Wenn Nutzungsfreiheit an Weitergabepflichten geknüpft ist

Copyleft Lizenzen verfolgen ein anderes Modell. Sie erlauben Nutzung, Veränderung und Weitergabe, knüpfen die Weitergabe aber an Bedingungen. Vereinfacht gesagt: Wer Software unter bestimmten Copyleft Lizenzen verteilt und sie bearbeitet oder mit eigener Software zu einem Gesamtwerk verbindet, muss unter Umständen auch den zugehörigen Quellcode unter den Lizenzbedingungen bereitstellen.

Wie weit diese Pflicht reicht, hängt stark von der jeweiligen Lizenz und der technischen Einbindung ab. Deshalb ist „Copyleft“ keine einheitliche Risikokategorie.

Bei der Einordnung wird häufig zwischen drei Wirkungsweisen unterschieden:

• Starkes Copyleft kann bei Verbreitung eines abgeleiteten oder kombinierten Werks weitreichende Pflichten für den vollständigen betroffenen Quellcode auslösen.
• Schwächeres Copyleft bezieht sich oft auf bestimmte Dateien, Bibliotheken oder Änderungen an der betreffenden Komponente.
• Netzwerkbezogenes Copyleft kann auch dann relevant werden, wenn Software nicht verteilt, sondern über ein Netzwerk für Nutzer bereitgestellt wird.

Die GPL wird oft als Beispiel für starkes Copyleft genannt. Die LGPL enthält für Bibliotheken typischerweise differenziertere Anforderungen. Die MPL arbeitet in vielen Konstellationen eher dateibezogen. Die AGPL kann bei der Bereitstellung einer Anwendung über ein Netzwerk zusätzliche Pflichten auslösen. Diese grobe Einordnung ersetzt aber keine Prüfung der konkreten Lizenzfassung und des konkreten Einsatzes.

Warum Copyleft bei eigener Software heikel werden kann

Für Unternehmen ist Copyleft vor allem dann kritisch, wenn eigene Software ein wesentlicher Teil des Geschäftsmodells ist. Das kann ein lizenziertes Produkt, eine kundenindividuelle Entwicklung, eine Plattform oder ein SaaS Angebot sein.

Die zentrale Frage lautet nicht pauschal: „Dürfen wir GPL Software einsetzen?“ Die richtige Frage lautet: „Welche Verpflichtungen entstehen durch diese konkrete technische Nutzung, und passen sie zu unserem Vertriebs und Schutzkonzept?“

Heikel werden insbesondere diese Fälle:

• Quellcode einer Copyleft Komponente wird verändert und anschließend mit dem Produkt ausgeliefert.
• Copyleft Code wird direkt in eigenen Code übernommen.
• Eine Bibliothek wird so eingebunden, dass ein einheitliches Gesamtwerk entstehen könnte.
• Die Anwendung wird als Service angeboten und eine Lizenz enthält Pflichten für die Netzwerknutzung.
• Vertragliche Zusagen gegenüber Kunden verlangen, dass die Lösung frei von Offenlegungspflichten oder bestimmten Open Source Anteilen ist.

Ob eine Verbindung zweier Programme rechtlich als abgeleitetes oder einheitliches Werk einzuordnen ist, lässt sich nicht allein anhand eines Schlagworts wie „dynamisch gelinkt“ beantworten. Die technische Architektur ist wichtig, aber nicht das einzige Kriterium. Schnittstellen, Kopplungsgrad, Art der Kommunikation, Umfang eigener Änderungen und Lizenztext müssen zusammen betrachtet werden.

Ein verbreiteter Fehler ist die Annahme, Copyleft Pflichten beträfen nur den ursprünglich übernommenen Code. Je nach Lizenz und Einbindung kann die Reichweite größer sein. Der umgekehrte Fehler ist ebenso problematisch: Nicht jeder Einsatz einer Copyleft Komponente zwingt automatisch zur Offenlegung der gesamten Anwendung. Pauschale Freigaben und pauschale Verbote helfen deshalb selten.

Open Source Anteile von Beginn an dokumentieren

Eine belastbare Dokumentation entsteht nicht kurz vor der Auslieferung. Sie muss Teil des Entwicklungsprozesses sein. Das Kerninstrument ist ein Komponentenverzeichnis, häufig auch als Software Stückliste bezeichnet.

Für jede verwendete Open Source Komponente sollte mindestens festgehalten werden:

• Name der Komponente und Hersteller oder Community Projekt
• verwendete Version
• Bezugsquelle, etwa Repository oder Paketquelle
• erkannte Lizenz oder Lizenzkombination
• Zweck der Komponente im System
• Art der Einbindung, etwa eigenständiger Dienst, Bibliothek oder übernommener Quellcode
• eigene Änderungen an der Komponente
• zuständige Person oder Team
• Prüfergebnis, Auflagen und Freigabestatus
• erforderliche Hinweise, Lizenztexte und Quellcodeangebote

Wichtig ist die Verbindung zwischen Dokumentation und tatsächlichem Build. Eine manuell gepflegte Liste veraltet schnell. Nutze deshalb, soweit technisch möglich, Daten aus Paketverwaltung, Build Prozess und Quellcodeverwaltung. Automatisierte Werkzeuge können Abhängigkeiten erkennen, bekannte Lizenzinformationen zuordnen und Auffälligkeiten melden.

Automatisierung ist jedoch kein Freifahrtschein. Sie erkennt nicht zuverlässig, ob ein Codefragment kopiert wurde, ob Lizenzinformationen falsch hinterlegt sind oder ob eine technische Integration eine rechtliche Neubewertung erfordert. Gerade bei Copyleft Befunden braucht es eine fachliche Prüfung durch Entwicklung, Einkauf und Rechtsfunktion.

Ein praktikabler Freigabeprozess für Projekte

Ein guter Prozess soll Teams nicht ausbremsen. Er muss klar machen, wann eine Komponente ohne Zusatzprüfung genutzt werden darf und wann eine Freigabe erforderlich ist.

In der Praxis bewährt sich eine einfache Einteilung:

• Standardfreigabe für definierte, risikoarme Lizenzen, sofern die vorgesehenen Hinweis und Dokumentationspflichten erfüllt werden.
• Prüffreigabe für Lizenzen mit besonderen Bedingungen, unklarer Herkunft, mehreren Lizenzoptionen oder relevanten Patentklauseln.
• Sperrung oder Einzelfallentscheidung für Copyleft Lizenzen, unbekannte Lizenzen und Komponenten ohne nachvollziehbare Herkunft.

Die Freigabe sollte nicht nur die Lizenz nennen. Sie sollte konkrete Nutzungsbedingungen enthalten. Beispiel: „Einsatz nur als separater interner Dienst, keine Änderungen, keine Auslieferung an Kunden“ oder „Nutzung zulässig, sofern Lizenztext und Copyright Hinweise in die Produktdokumentation aufgenommen werden“.

Wenn sich Architektur, Version oder Vertriebsmodell ändern, muss die Bewertung erneut auf den Tisch. Eine ursprünglich interne Anwendung kann später als Kundenlösung verkauft werden. Eine Komponente kann bei einem Update ihre Lizenz ändern. Beides sind typische Auslöser für eine erneute Prüfung.

Passende Seminare und Termine zur Vertrags und Lizenzpraxis findest du bei uns auf cmt.de.

Diese Prüffragen gehören vor jeden Release

Vor einem Release oder einer Auslieferung solltest du die folgenden Punkte verbindlich abfragen:

• Ist das Komponentenverzeichnis vollständig und entspricht es dem aktuellen Build?
• Sind für alle Komponenten Lizenz und Version nachvollziehbar dokumentiert?
• Gibt es Copyleft Lizenzen oder Komponenten mit unklarer Lizenzlage?
• Wurde bei kritischen Komponenten die technische Einbindung geprüft?
• Sind Änderungen an fremdem Open Source Code dokumentiert?
• Werden erforderliche Lizenztexte, Notices und Copyright Hinweise korrekt ausgeliefert?
• Bestehen Pflichten zur Bereitstellung von Quellcode, Installationsinformationen oder Änderungsnachweisen?
• Passen die Lizenzpflichten zu Kundenverträgen, Geheimhaltungszusagen und dem geplanten Vertriebsmodell?
• Ist klar dokumentiert, wer die Nutzung freigegeben hat und unter welchen Bedingungen?

Fazit: Nicht die Menge entscheidet, sondern die Kontrolle

Open Source Software wird nicht dadurch riskant, dass sie im Projekt vorkommt. Riskant wird sie, wenn niemand weiß, welche Komponenten verwendet werden, welche Lizenz gilt und wie sie eingebunden sind. Permissive Lizenzen sind oft gut beherrschbar, verlangen aber saubere Hinweise und Dokumentation. Copyleft Lizenzen brauchen eine präzise Prüfung, weil ihre Pflichten bei eigener Software, Kundenlieferungen und SaaS Modellen erheblich sein können.

Schaffe deshalb einen verbindlichen Prozess aus Erfassung, technischer Bewertung, Lizenzprüfung, Freigabe und Release Kontrolle. So wird Open Source vom ungeklärten Risiko zu einem steuerbaren Bestandteil deiner Softwareentwicklung.