Die Pfauen und die Krähe in der IT-Sicherheit

Ein Erfahrungsbericht über Open Source, Wettbewerb, Durchsetzung von Rechten und die Frage, wie man ein faires und nachhaltiges Open-Source-Ökosystem verteidigt.

Zusammenfassung

Dieser Bericht beschreibt einen realen Fall missbräuchlicher Nutzung von Open-Source-Software am Beispiel von OPENVAS, dem von uns entwickelten Open-Source-Schwachstellenmanagement. Ein Marktteilnehmer hatte systematisch Open-Source-Code und -Daten unter Verletzung von Lizenz- und Urheberrechten in eigene Produkte integriert und als eigene Leistung ausgegeben. Wir berichten hier über die technischen, forensischen und juristischen Schritte, die notwendig waren, um den Missbrauch nachzuweisen und wirksam zu unterbinden, einschließlich Abmahnung, einstweiliger Verfügung und der Einbindung von Plattformbetreibern. Besonderer Augenmerk liegt auf einem in Deutschland erstmals erfolgreich geführten Verfahren zur Durchsetzung der Open Database License (ODbL). Der Beitrag richtet sich an Open-Source-Entwickler, Unternehmen und Anwender und zeigt, welche Voraussetzungen und Aufwände mit der Durchsetzung von Open-Source-Lizenzen verbunden sind – und warum deren konsequente Verteidigung entscheidend für ein faires und nachhaltiges Open-Source-Ökosystem ist.

Eine vertiefende Analyse aus juristischer Fachperspektive ist bei IFROSS veröffentlicht.

Die Pfauen und die Krähe in der IT-Sicherheit

Die Pfauen und die Krähe

Fab. Aesop. 188. Phaedrus lib. I. Fab. 3.

Eine stolze Krähe schmückte sich mit den ausgefallenen Federn der farbigten Pfaue und mischte sich kühn, als sie gnug geschmückt zu sein glaubte, unter diese glänzende Vögel der Juno.
Sie ward erkannt; und schnell fielen die Pfaue mit scharfen Schnäbeln auf sie, ihr den betrügerischen Putz auszureißen.
Lasset nach! schrie sie endlich, ihr habt nun alle das Eurige wieder. Doch die Pfaue, welche einige von den eignen glänzenden Schwingfedern der Krähe bemerkt hatten, versetzten:
Schweig, armselige Närrin, auch diese können nicht dein sein! – und hackten weiter.

Wenn sich Anbieter von Softwareprodukten mit fremdem Federn schmücken wollen, bietet sich Open Source als einfache Quelle an. Natürlich ist das nicht mit den Open Source Lizenzen vereinbar, aber wen kümmert’s. „Was soll schon passieren?“ scheinen sich manche zu sagen, die sogar eigene Geschäftsmodelle auf der Arbeit anderer aufbauen, die sie noch dazu als eigene Werke ausgeben. Wer sich dagegen wehren will, muss einen weiten Weg gehen, und macht dabei viele interessante und nicht nur angenehme Erfahrungen. Wir haben das getan, und hier ist unser Bericht dazu.

Wir stellen mit OPENVAS ein weltweit beliebtes und verbreitetes Open Source Schwachstellenmanagement her. Durch unser Projekt wird die Suche nach Sicherheitslücken von IT-Systemen automatisierbar. Wir haben etwa 200.000 Tests, um Sicherheitslücken zu finden, dazu Scanner, um diese auszuführen und Applikationen, um den ganzen Prozess vom Scan bis zum Bericht zu steuern. Wir stellen eine Open Source Lösung kostenlos bereit sowie zusätzliche Module und Leistungen für unsere zahlenden Kunden. Dadurch finanzieren wir uns und ermöglichen auch die kostenlose Bereitstellung für die Community. Wir sind mit dem, was wir tun, gegenüber dem proprietären Mitbewerbern (große internationale Anbieter, meist aus den US) mindestens konkurrenzfähig, teilweise sogar besser. Das macht auch unseren Code zu einer verlockenden Beute.

Wir kennen viele kleine Anbieter auf der ganzen Welt, die auf Basis unserer Open Source Lösung eigene Produkte anbieten. Größere schließen mit uns Verträge. Viele halten sich an die Lizenzen, andere nicht. Das ärgert uns natürlich, aber andererseits wollen wir unsere Energie lieber für unser Projekt einsetzen als Rechtsstreitigkeiten irgendwo auf der Welt zu führen. Aber wenn es ein Mitbewerber zu wild treibt, dann handeln wir. „Zu wild treiben“ bedeutet: Copyright Vermerke in unserem Code zu verändern und unseren Namen durch den eigenen Firmennamen zu ersetzen, Attributierungspflichten zu ignorieren, Open Source Lizenzen zu verletzen.

Einen solchen Fall haben wir gerade erfolgreich verfolgt. Wir glauben das die Geschichte für verschiedene Gruppen interessant ist: für Open Source Entwickler, Projekte und Unternehmen, für an Rechtsfragen interessierte Personen (immerhin haben wir auf unserem Wege einen juristischen Präzedenzfall geschaffen – dazu später mehr) und auch die Anwender von Open Source Produkten und Projekten, die sich für die Sicherheit ihrer Supply Chain interessieren.

Was es braucht, um sich gegen missbräuchliche Nutzung erfolgreich zu wehren sind im Wesentlichen fünf Dinge: Zeit, Geld und Expertise sowie starke Nerven und viel Geduld. Zur Expertise gehört die juristische: das bedeutet einen guten Anwalt, der sich mit Open Source Lizenzen auskennt. Natürlich ist es auch ein entscheidender Faktor, an welchem Gerichtsstand man sich verteidigen möchte, da wird man immer das Land bevorzugen, in dem sich der eigene Firmensitz befindet, denn das hat einige Vorzüge, die sich auch in den Kosten bemerkbar machen. Nach welchem Recht verhandelt wird, ist wichtig. Wer sich international verteidigen will, braucht auch eine entsprechende ausgestattete oder vernetzte Anwaltskanzlei. Wer nicht gerade ein großes Unternehmen ist und reichlich Ressourcen besitzt, wird diesen Weg nicht wählen wollen. Die Verfahren, von denen hier die Rede sein wird, haben wir daher in Deutschland geführt, wo auch der Hauptsitz unseres Unternehmens ist. Ein anderer Teil der Expertise ist die technische und forensische. Man muss schließlich den Nachweis führen, dass der eigene Code in der missbräuchlichen Nutzung verbaut wurden. Wenn die Gegenseite die Open Source Pflichten nicht erfüllt und den Quellcode zur Verfügung stellt, muss man sich den entsprechenden Code beschaffen und den Nachweis führen, dass der eigene Anteil daran Bestandteil der Produkte ist, die die Gegenseite in Verkehr bringt. Es bietet sich an, über Dritte einen Kauf der Produkte zu tätigen, um den Nachweis führen zu können.

Wenn der Nachweis geführt ist, folgen die nächsten Schritte: Abmahnung erstellen, und sollte der Hersteller nicht reagieren, bei Gericht eine einstweilige Verfügung erwirken. Diese verhindert das Inverkehrbringen der Produkte, bis der Mangel (die missbräuchliche und nicht lizenzgemäße Nutzung der Software) abgestellt ist. In unserem Fall wurden die Produkte auch über Hyperscaler Plattformen, wie zum Beispiel Microsoft Azure, verbreitet. Hier kann man den Betreiber auf der Basis des Digital Services Act darauf hinweisen, dass Lizenzen verletzt werden, was dazu führt, dass die Produkte dort nicht mehr vertreiben werden können, weil Microsoft (im Fall von Azure) diese im Store sperrt, wenn man dort z.B. auf die einstweilige Verfügung hinweist. Das ist eine sehr schöne Sache, weil es den Produktanbieter zusätzlich unter Druck setzt. Natürlich ist das nur möglich, wenn man einen plausiblen Nachweis hat, dessen Erlangung ein gutes Stück Arbeit sein kann, je nachdem wieviel Energie der Produktanbieter aufgewendet hat, um die nicht lizenzgemäße Nutzung von Drittkomponenten zu verschleiern. Wir haben die Erfahrung gemacht, das fortgeschrittene Verschleierungstechniken weniger häufig genutzt werden als erwartet: wir konnten einen eindeutigen Nachweis führen, sowohl darüber, dass es sich um unsere Quellen handelt, als auch darüber, dass es nicht um ein Versehen handelt.

In unserem Fall wurden zudem Erweiterungen mit unseren Bibliotheken verlinkt und dabei das Copyleft missachtet. Dabei wurde, um die Lizenzverletzung zu verschleiern, unser Copyright Hinweis den eigenen Erweiterungen hinzugefügt. Als wir diese Manipulationen entdeckten, haben wir natürlich über die Dreistigkeit gestaunt und auch gleich etwas weiter geforscht. Wir haben dabei festgestellt, dass wir nicht die einzigen Opfer des Anbieters sind, haben uns aber entschlossen uns erst einmal auf unsere Verfahren zu konzentrieren.

Wir hatten drei Ziele, als wir das Projekt begonnen haben: die missbräuchliche Nutzung abzustellen, möglicherweise Schadensersatz zu bekommen und am Ende die nicht ganz unerheblichen Kosten der Verfahren der Gegenseite aufzuerlegen. Ein Ziel haben wir bereits erreicht, unsere Verfügung ist rechtswirksam und kann auch nicht mehr angefochten werden.

Einen schönen juristischen Erfolg haben wir mit unseren Verfahren bereits erzielt, und der hat etwas mit der Lizenzierung der Datenbankinhalte unseres Produktes zu tun. Zum Hintergrund: unsere Lösungen bestehen aus drei Komponenten: dem Anwendungs- und Systemcode und zugehörige Binaries, viele tausend Testskripte zur Schwachstellensuche, die zusammen mit Informationen zu bereits bekannten Schwachstellen und Input zu deren Behebung Datenbank eine große Datenbank bilden. Diese Datenbank ist für unser Communityprodukt unter der Open Database Public License (ODbL) lizenziert. Die ODbL erlaubt es, eine Datenbank frei zu kopieren, weiterzugeben, zu verändern und zu nutzen (z.B. für eigene Anwendungen oder Analysen). Gleichzeitig stellt sie sicher, dass abgeleitete Datenbanken unter denselben Freiheiten verfügbar bleiben. Die bekannte Geodatenbank OpenStreetMap steht unter der ODbL. Wer eine ODbL Datenbank mit eigenen proprietären Inhalten mischt, muss auch diese modifizierte Datenbank unter die ODbL stellen, es handelt sich daher um eine Copyleft Lizenz. In unserem Verfahren wurde zum ersten Mal in Deutschland eine ODbL Datenbank erfolgreich in einem Lizenzstreit verteidigt. Dadurch wurde eine Musterentscheidung erzielt, auf die sich andere nun beziehen können. Das freut uns sehr.

Und wir machen noch weiter: Aktuell haben wir Klage erhoben. Hier wird es um die urheberrechtliche und wettbewerbsrechtliche Thematik gehen, und auch das Thema Schadensersatz adressiert werden.

Soweit die Zusammenfassung eines Vorgangs, der sich über einige Monate hinzugezogen hat und noch in die Zukunft reicht. Wenn ich heute ein Fazit ziehe, dann ist es positiv: wir haben bisher in allen wichtigen Belangen gewonnen. Wir machen Open Source stärker, wenn wir die ihre Regeln auch durchsetzen. Open Source ist eine Grundlage unseres Geschäftsmodells, deswegen ist es uns wichtig, diese Grundlage zu verteidigen. Andererseits ist der Aufwand erheblich. Unser Geschäftszweck ist es, unseren Nutzern die größtmögliche Sicherheit ihrer IT-Infrastruktur zu ermöglichen und nicht, Rechtsstreitigkeiten zu führen. Wir möchten das nur sehr dosiert tun und auch nur dort, wo die Erfolgsaussichten groß und die Rahmenbedingungen günstig sind (wie in unserem Fall hier, wo wir im gewohnten Rechtssystem agieren können). Unser Dank gilt unserer hervorragenden rechtlichen Vertretung durch Dr. Till Jaeger von JBViniol und der großartigen forensischen Expertise von DN-Systems – ohne deren Hilfe hätten wir diese Erfolge nicht erreichen können.

Wir haben eine Liste mit etwas über 100 Verdachtsfällen, wir bekommen sehr regelmäßig Hinweise von Partnern, Community und Mitarbeitenden über solche Fälle. Nicht immer sind die Rahmenbedingungen so günstig wie im vorliegenden Fall, und nicht immer ist die Relevanz groß genug. Dort wo es so ist, werden wir – trotz des großen Aufwandes – wieder gegen Anbieter vorgehen. Wir wollen ein faires und gesundes Open Source Ökosystem, und besonders dreiste Verstöße – wie der hier berichtete – triggern uns natürlich. Mit diesem Bericht wollen wir auch andere ermutigen, und – ganz der Open Source Idee folgend – unser Wissen teilen.

Download
LG Berlin II – Urteil, Az. 15 O 299/25 (geschwärzte Fassung) – PDF