Open-Source-Software: Lizenzen und Risiken im Unternehmen

Praktisch jede Unternehmenssoftware enthält heute Open-Source-Komponenten. Das ist eine grossartige Ressource, doch “frei” bedeutet nicht “ohne Regeln”. Jede Komponente kommt mit einer Lizenz, die Pflichten auferlegt, und diese zu ignorieren setzt konkreten Risiken aus: Verlust der Kontrolle über den eigenen Code, Anfechtungen, Blockaden bei der Due Diligence. Das Thema betrifft ebenso jene, die Software entwickeln, wie jene, die sie bloss nutzen.

Open Source heisst nicht ohne Bindungen

Das grundlegende Missverständnis ist die Annahme, Open-Source-Software sei gemeinfrei. Ist sie nicht: Sie ist urheberrechtlich geschützt, und wer sie veröffentlicht, gewährt die Nutzung unter bestimmten Bedingungen über eine Lizenz. Die Komponente zu nutzen bedeutet, diese Lizenz zu akzeptieren. Wenn Sie ihre Bedingungen nicht einhalten, verstossen Sie gegen die Bestimmungen, die Sie zur Nutzung berechtigten. Die Frage lautet nicht “darf ich sie nutzen”, sondern “unter welchen Bedingungen”.

Die zwei grossen Lizenzfamilien

Vereinfacht teilen sich Open-Source-Lizenzen in zwei Kategorien mit gegensätzlicher Logik:

• Permissiv: Sie erlauben eine sehr weitreichende Nutzung, auch in kommerziellen und geschlossenen Produkten, und verlangen in der Regel wenig: die Copyright-Hinweise und den Lizenztext beizubehalten. Sie sind im Unternehmenskontext am einfachsten zu handhaben.
• Copyleft: Sie verlangen, dass abgeleitete Werke unter bestimmten Bedingungen unter derselben Lizenz verteilt werden und der Quellcode verfügbar gemacht wird. Ziel ist, frei zu halten, was aus freier Software entsteht.

Innerhalb des Copyleft ist die entscheidende Unterscheidung jene zwischen starkem und schwachem Copyleft: Ersteres kann sich auf das gesamte Werk “ausbreiten”, das die Komponente integriert, Letzteres beschränkt die Pflicht auf die geänderte Komponente allein. Für ein Unternehmen, das proprietäre Software entwickelt, kann die unwissentliche Integration einer Komponente mit starkem Copyleft die Pflicht nach sich ziehen, den eigenen Code offenzulegen.

Die konkreten Risiken für das Unternehmen

• Kontamination des proprietären Codes: Copyleft-Komponenten auf eine mit einem geschlossenen Produkt unvereinbare Weise zu nutzen, kann die Pflicht zur Offenlegung des Quellcodes schaffen oder die Notwendigkeit, Teile des Produkts zu entfernen und neu zu schreiben.
• Verletzung der Bedingungen: Die Pflichten (Nennung, Lizenztext, Quellcode) nicht einzuhalten, setzt Ansprüchen der Rechteinhaber aus.
• Blockade bei der Due Diligence: Bei einer Investition, Übernahme oder einem Verkauf ist die Analyse der Open-Source-Lizenzen inzwischen Standard. Schlecht verwaltete Komponenten bringen Risiken ans Licht, die den Wert mindern oder das Geschäft blockieren.
• Verborgene Abhängigkeiten: Eine Komponente ruft andere auf, jede mit ihrer eigenen Lizenz. Das Risiko nistet sich in den indirekten Abhängigkeiten ein, die niemand geprüft hat.
• Sicherheit: Nicht aktualisierte Komponenten bringen bekannte Schwachstellen mit. Das ist ein operatives Risiko, noch bevor es ein rechtliches ist.

Wie man Open Source ohne Überraschungen handhabt

Die Lösung ist nicht, es zu verbieten, das wäre unrealistisch, sondern es zu steuern:

• Inventar der Komponenten: eine Aufstellung der genutzten Software und ihrer Lizenzen führen, indirekte Abhängigkeiten inbegriffen.
• Interne Policy: festlegen, welche Lizenzkategorien frei zugelassen sind, welche eine Beurteilung erfordern und welche in bestimmten Produkten zu vermeiden sind.
• Prüfung vor der Integration: die Lizenz einer Komponente prüfen, bevor man sie einbindet, nicht danach.
• Einhaltung der Mindestpflichten: Copyright-Hinweise, Lizenztexte und Nennungen aufbewahren. Das sind einfache Pflichten, die vernachlässigt unverhältnismässige Probleme schaffen.
• Vorsicht bei Verteilung: Viele Copyleft-Pflichten werden ausgelöst, wenn die Software an Dritte verteilt wird. Wer die Software nur intern nutzt, hat oft andere Bindungen als wer sie an Kunden liefert.

Kurz zusammengefasst

• Open Source ist urheberrechtlich geschützt: Die Lizenz auferlegt einzuhaltende Bedingungen.
• Permissive Lizenzen sind einfach; Copyleft, besonders starkes, kann zwingen, den eigenen Code offenzulegen.
• Die grössten Risiken sind Kontamination des proprietären Codes, Verletzungen und Blockaden bei der Due Diligence.
• Es braucht Governance: Inventar, Policy, vorgängige Prüfung und Einhaltung der Nennungspflichten.

Wie wir helfen

Wir helfen Ihnen, eine Open-Source-Policy aufzubauen, die Lizenzen der genutzten Komponenten zu prüfen und Ihre Software vor einer Verteilung oder einer ausserordentlichen Transaktion abzusichern. Sprechen wir über Ihre Lizenzen.