Compliance und Risiko
Der richtige Umgang mit Open Source-Lizenzen
Der Einsatz von Open-Source-Codekomponenten hat explosionsartig zugenommen. Der Preis dafür ist jedoch eine erweiterte Angriffsfläche mit neuen Risiken etwa für rechtliche Belange und geistiges Eigentum.
Save to Folio
Originalartikel von Trend Micro
Im Zuge der Beschleunigung der digitalen Transformation hat der Einsatz von Open-Source-Codekomponenten explosionsartig zugenommen, bieten sie doch Anwendungsentwicklungsteams Schnelligkeit, Flexibilität, Erweiterbarkeit und Qualität für ihre Arbeit. Der Preis dafür ist jedoch eine erweiterte Angriffsfläche mit neuen Risiken etwa für rechtliche Belange und geistiges Eigentum. Open Source-Software untersteht natürlich dem Schutz des geistigen Eigentums, insbesondere dem Urheberrecht. Sobald ein Entwickler quelloffene Software in seiner Anwendung verwendet, ist sein Unternehmen verpflichtet, alle in der zugehörigen Lizenz festgelegten Bedingungen einzuhalten. Weil das nicht immer einfach ist, haben viele Unternehmen spezielle Open-Source-Rechtsberater unter Vertrag. Wo liegen die brennenden Fragen?
Veröffentlicht ein Unternehmen eine Anwendung, die Open Source-Software enthält, ohne die Anforderungen der Lizenz zu erfüllen, begeht es eine Verletzung des geistigen Eigentums und ist rechtlich haftbar zu machen. Nach Angaben von Snyk sind heutzutage mindestens 80 % aller Anwendungen Open-Source. Unternehmen müssen verstärkt auf die Nutzung von „illegaler“ Open-Source achten. Nicht nur der Inhaber des Urheberrechts kann die Organisation wegen Verletzung verklagen, sondern es gibt auch gemeinnützige Organisationen wie die Software Freedom Conservancy, die die Verwendung von Open Source-Software überwacht und bei Verstößen Klage erhebt. Diese Klagen führen nicht nur zu finanziellen Verlusten, sondern können auch zu einem Albtraum für Kunden und konsequenterweise für den guten Ruf des Unternehmens werden!
Bei Open Source-Lizenzen genügt doch eine Fußnote als Hinweis, oder?
Es ist wichtig zu wissen, mit welcher Art von Lizenz die Entwickler zu tun haben, damit die besten Verfahrensweisen angewendet werden können. Es gibt zwei Haupttypen von Open Source-Lizenzen. Freizügige (Permissive) Lizenzen folgen grundlegenden Konzepten des Urheberrechts und verlangen im Wesentlichen nur die Nennung des ursprünglichen Entwicklers und nicht viel mehr. Copyleft-Lizenzen (die das Gegenteil des Urheberrechts sein sollen) greifen dagegen auf das traditionelle Konzept der Softwarefreiheit zurück und bauen dieses in die Lizenzanforderungen ein, um die gemeinsame Nutzung von Code zu fördern.
Freizügige Lizenzen sind aufgrund ihrer Einfachheit und unkomplizierten Nutzung die geschäftsfreundlichere von den beiden Typen. Daher ist es nicht verwunderlich, dass sie mit 76 % im Jahr 2020 die meisten Lizenzen in dem Bereich ausmachen. Eine häufig verwendete freizügige Lizenz ist die MIT-Lizenz, die oft wegen ihrer kurzen und einfachen Form gewählt wird. Diese Lizenz gibt den Nutzern die volle Erlaubnis, die Software weiterzuverwenden, mit der einzigen Bedingung, dass der Lizenztext und der Copyright-Vermerk bei der Verteilung der Software enthalten sein müssen.
Copyleft-Lizenzen, in der Regel Versionen der General Public License (GPL), stellen ein Risiko dar, wenn sie in der Codebasis einer kommerziellen Softwareanwendung verwendet werden, da sie zu Problemen mit dem geistigen Eigentum der gesamten Anwendung führen können. Aus diesem Grund setzen viele Unternehmen die Risikostufe für GPL-Lizenzen in ihrem System auf hoch.
Kürzlich ist als Ergebnis zahlreicher hinzugekommener Open-Source-Lizenzen eine neue Kategorie entstanden, weil große Unternehmen Open Source-Code übernehmen und als kommerziellen Dienst freigeben und damit die Vermarktung von Open-Source behindern. Diese dritte Art wird als verfügbare Quelle bezeichnet, und obwohl sie wie Open Source ist, unterscheidet sie sich technisch durch die zusätzlichen Einschränkungen, die erforderlich sind, um zu verhindern, dass Unternehmen daraus Kapital schlagen. Im Wesentlichen gibt es dem Autor die Möglichkeit, seinen Code offen für die Zusammenarbeit zur Verfügung zu stellen, verhindert aber, dass er als kommerzieller Dienst genutzt wird.
Wenn ein Entwickler auf Open Source-Code aufbaut, der einen möglichen Lizenzkonflikt aufweist, ist eine Risikoanalyse erforderlich. Das Team muss dann entscheiden, ob es die Haftung für den Anwendungscode abmildern kann, oder ob er so abgeändert werden muss, dass dieser Abschnitt entfernt wird. Doch die Prozedur verlängert die Frist bis zur Vermarktung. Deshalb haben die Rechtsabteilungen der Unternehmen oft vorgegebene Richtlinien für die Open-Source-Lizenzierung.
Ist quelloffene Software ohne Lizenz frei verfügbar?
Kurz gesagt, nein. Standardmäßig ist die Software urheberrechtlich geschützt und darf ohne eine Lizenz nicht verwendet werden, auch wenn sie als Open Source bezeichnet wird. Es ist die Lizenz, die die Erlaubnis gibt, die Software zu verwenden, zu kopieren, zu verteilen oder zu verändern, ohne das Risiko einer Rechtsverletzung, solange die Bedingungen erfüllt sind.
Angepasste Open Source-Lizenzen
Entwickler schreiben manchmal ihre eigenen Lizenzen oder ändern die Bedingungen einer Standardlizenz. Obwohl dies oft in guter Absicht geschieht, kann es zu weiterer Unklarheit führen. Es gibt einige ziemlich wilde Lizenzen, wie die Beerware-Lizenz, die im Grunde besagt, dass man dem Autor ein Bier kaufen oder ihm zu Ehren trinken sollte, wenn einem die Software gefällt. Eine andere ist die Chicken Dance-Lizenz, die als Alternative zur Standard-GPL-Anforderung, den Code zu teilen, ein Video von Ihnen fordert, wie Sie den Hühnertanz aufführen.
Ein weiteres Beispiel für eine solche abgeänderte Lizenz ist die JSON-Lizenz für JavaScript Object Notation, eine beliebte Komponente für den Datenaustausch. Sie modifiziert die freizügige MIT-Standardlizenz mit einer zusätzlichen Bedingung: „Die Software soll für das Gute, nicht für das Böse verwendet werden.“ Das ist sicherlich gut gemeint, aber viele Unternehmen lehnen diese Lizenz ab, da die Begriffe „gut“ und „böse“ auslegungsfähig sind.
Jedes Unternehmen muss für sich selbst entscheiden, wie hoch seine Risikotoleranz ist und welche Lizenzen es zulassen will. Doch je vager ein Begriff ist, desto mehr Bedenken gibt es aus rechtlicher Sicht. Daher sind diese angepassten Lizenzen oft verpönt oder werden in den Open Source-Richtlinien des Unternehmens sogar ganz verboten.
Sollten die Entwickler die Gesetze des von ihnen verwendeten Codes kennen?
Entwickler werden nicht wegen ihres juristischen Fachwissens eingestellt. Ihre Aufgabe ist es, innovativ zu sein, gut zu entwickeln und schnell zu arbeiten. Wichtig ist, daran zu denken, dass es ein Irrtum ist, Open-Source-Code sei „frei“. Ursprünglich ging es um „Freie Software“, wobei sich die Bewegung für die Freiheit, Software zu verstehen und zu verändern, einsetzte.
Unternehmen wissen gar nicht, dass Open-Source-Code verwendet wird, da viele Unternehmen ihre interne Anwendungsentwicklung ständig ausbauen. Auch sind die Lizenzen sind oft nicht ganz einfach zu verstehen. Bei JSON etwa könnte ein Entwickler könnte denken, es sei in Ordnung, da es sich um kommerzielle Software handelt und nicht um Malware oder irgendetwas „Böses“. Ein Anwalt wäre jedoch in der Lage, das Risiko zu erkennen, das sich aus der Zweideutigkeit des Begriffs ergibt, und das Risikoprofil der Lizenz richtig zuzuordnen. Um das Lizenzierungsrisiko zu mindern, lassen viele Organisationen ihre Entwickler in Open-Source-Recht schulen.
Das Paradoxon von Open-Source-Lizenzen bei den Abhängigkeiten
Bei dem Tempo, in dem Entwickler unter Verwendung einer Vielzahl von Code-Ressourcen arbeiten, scheint es praktisch unmöglich, mit dem Management der Risiken und Verbindlichkeiten Schritt zu halten. Ganz zu schweigen von der geringen Transparenz, die Sicherheitsteams in der Entwicklungs-Pipeline haben. Eine weitere Schwierigkeit, die mit der Verwendung von Open-Source-Bibliotheken einhergeht, ist der fehlende Einblick in die indirekten Abhängigkeiten. Was passiert, wenn ein Entwickler eine Open Source-Komponente verwendet, die mit mehreren indirekten Abhängigkeiten von anderen Open-Source-Codes erstellt wurde? Das kann wie ein unendliches Paradoxon wirken, denn Sie haften nicht nur für die Lizenzbedingungen der direkten Abhängigkeit, sondern auch für alle indirekten Abhängigkeiten, die quelloffener Code bei der Erstellung der größeren Open Source-Komponente verwendet.
Open Source-Lizenzierung hat Auswirkungen auf die Integrität Ihrer Software Supply Chain
Angriffe auf die Supply Chain stehen bei vielen IT-Teams ganz oben auf der Liste ihrer Sorgen. Deswegen sind sie bemüht, die Integrität der Supply Chain zu gewährleisten. Die Einhaltung von Richtlinien ist hierbei von zentraler Bedeutung, so dass Organisationen wie die Linux Foundation nach einer Lösung gesucht haben. Das OpenChain-Projekt wurde als effektive Zertifizierung für die Einhaltung von Open Source-Lizenzen in der Software-Supply-Chain geschaffen. Im Wesentlichen geht es darum, die gesamte Kette zu stärken und sicherzustellen, dass jeder Abschnitt vertrauenswürdig ist und den für die Zertifizierung festgelegten Standard erfüllt. Die neueste OpenChain-Spezifikation ist die ISO/IEC 5230:2020-Norm, die „die wichtigsten Anforderungen an ein hochwertiges Programm zur Einhaltung von Open Source-Lizenzen spezifiziert, um einen Maßstab zu schaffen, der das Vertrauen zwischen Organisationen stärkt, die Softwarelösungen austauschen, die aus Open-Source-Software bestehen.“
Wie lassen sich rechtliche Risiken minimieren?
Es gibt Programme, die über Datenbanken mit Lizenzen und vordefinierten Risikoprofilen verfügen. Die Teams der Rechtsabteilung können eine Automatisierung einrichten, so dass jeder Open Source-Code mit Lizenzkonflikten eine Kennzeichnung erhält. Diese Programme stützen sich auf eine Datenbank mit Open-Source-Bibliotheken, die Tausende von Lizenzen und Lizenzfamilien enthalten. Die Programme helfen auch dabei, den Überblick über die Lizenzen zu behalten, die ein Unternehmen verwendet, und können einen Bericht mit all diesen erstellen, der bei der Verbreitung von Anwendungen berücksichtigt wird. Die Schulung von Entwicklern zu den Gesetzen von Open-Source-Software ist ebenfalls eine wichtige Maßnahme zur Verringerung von möglichen Konflikten.
Trend Micro Cloud One - Open Source Security stützt sich auf die Snyk-Datenbank mit Tausenden von Open Source-Bibliotheken und den dazugehörigen Lizenzen. Diese Lösung überbrückt die beiden häufigsten Risiken von Open Source - Schwachstellen und Lizenzen - so dass alle Open Source-Risiken von einer einzigen Konsole aus zu kontrollieren und zu handhaben sind. Die Lösung unterstützt Sicherheitsteams und die Rechtsabteilung dabei, Risiken früher im Lebenszyklus der Softwareentwicklung zu erkennen und damit Zeit und Kosten für Korrekturen zu sparen.