Wie und in welcher Form darf Open Source Code in eigener, proprietärer Software genutzt werden? Die landläufigen Antworten auf diese Frage divergieren überraschend stark. Viele Unternehmen, die erfolgreich mit Softwareprodukten im Markt positioniert sind, sind der Auffassung, dass Open Source gleichzusetzen sei mit frei nutzbaren Code-Elementen / Bibliotheken, welche die Community dankenswerterweise bereitstellt. Dies ist aber nicht zwangsläufig der Fall. Eine unsorgfältige Nutzung von “vermeintlich” freier Software birgt große Risiken und kann sich bei Unternehmenstransaktionen / in Kaufvertragsverhandlungen oft als kritischer Punkt herauskristallisieren.
Hintergrund: Unterschiede in Open Source Lizenzen
Die Nutzungsrechte von Open Source sind nahezu unbeschränkt. Entscheidet sich ein Unternehmen bzw. ein Softwareentwickler eine bestimmte Software-Bibliothek, beispielsweise zum Generieren von pdf-Dokumenten, in die eigene Software einzubauen, so ist dies ohne Weiteres möglich. Das Unternehmen darf das finale Softwareprodukt beliebig distribuieren, vertreiben und vervielfältigen.
Hinsichtlich der Lizenzpflichten, die mit der Nutzung einhergehen, gibt es jedoch zwischen den verschiedenen Lizenzen starke Unterschiede. Grundsätzlich kann zwischen (1) freizügigen (permissive) Lizenzen und (2) restriktiven Lizenzen mit Copyleft-Effekt unterschieden werden.
Der Copyleft-Effekt besagt - stark vereinfacht gesagt -, dass jede Bearbeitung des Codes wiederum unter der gleichen Lizenz, also somit unter den gleichen Open Source Lizenzbestimmungen, freigegeben werden muss. Um das Ganze noch undurchsichtiger zu machen, unterscheiden sich die restriktiven Lizenzen hinsichtlich der Schärfe des Copyleft-Effekts. Was genau eine “Bearbeitung” des Codes genau bedeutet entscheidet sich in den Paragraphen der Lizenztexte, die freilich nur von ausgebildeten Juristen einwandfrei ausgelegt werden können. Während unter manchen Lizenzen die bloße Integration der unveränderten Software-Komponente in die eigene, proprietäre Software unproblematisch ist, kann unter anderen Lizenzen selbst dies den Copyleft-Effekt auslösen.
Die Beschaffenheit des Copyleft-Effekt war es auch, die Steve Ballmer (ehemaliger Microsoft CEO) 2001 dazu bewog, folgendes zu Protokoll zu geben: “Linux ist ein Krebsgeschwür, das in Bezug auf geistiges Eigentum alles befällt, was es berührt.“ Der Hintergrund: Linux wird unter einen restriktiven Open Source Lizenz entwickelt.
Sich im Dschungel der Open Source Lizenzen zurecht zu finden, ist nicht unbedingt einfach, da es mittlerweile eine Vielzahl von unterschiedlichen Lizenzen gibt. Eine - nicht abschließende - Übersicht der Lizenzen mit der weitesten Verbreitung:
Restriktive Open Source Lizenzen:
GNU General Public License (GPL)
Eclipse Public License 2.0
GPL 2.0 Classpath Exception
LGPL / LGPL 2.0
Mozilla Public License (MPL)
Microsoft Public License
Permissive Open Source Lizenzen:
MIT
BSD
Apache 2.0
Open SSL/SSLeay License
PHP License 3.01
JSON License
ZLIB License
Risikoeinschätzung bei ungeklärter Open Source Compliance
Große Unternehmen wie Microsoft, Adobe & SAP haben mittlerweile eine umfangreiches Open Source Compliance Management. Dies kann von kleinen und mittelständischen Softwareunternehmen nicht erwartet werden. Es obliegt dennoch der Sorgfaltspflicht der Geschäftsführung, die Einhaltung der Lizenzbestimmungen in der Softwareentwicklung zu überprüfen und sicherzustellen, sowie alle Softwareentwickler entsprechend einzuweisen.
Das Risiko eines Lizenzverstoßes ist somit in den meisten Fällen zwar gering, aber sollte sich das Risiko realisieren, steht oftmals ein kompletter Wertverlust der Software (und somit des Unternehmens) im Raum. Das Szenario ist folgendes: Ein Lizenzverstoß wird festgestellt (bspw. vom Entwickler der Open Source Bibliothek) und angezeigt. Je nach Umfang, ist entweder die gesamte proprietäre Software des Unternehmen ab diesem Zeitpunkt auch unter der Open Source Lizenz und es können keine Lizenzeinnahmen mehr durch den Vertrieb der Software generiert werden. Oder es wird eine hohe Entschädigungssumme geltend gemacht, zuzüglich zu umfangreichen Programmierarbeiten, um die Open Source Bibliotheken mit restriktiver Lizenz durch andere Komponenten zu ersetzen.
Dass tatsächlich ein Open Source Entwickler einen Lizenzverstoß entdeckt und konsequent verfolgt, ist bei kleinen und mittelständischen Unternehmen, die mit ihrem Softwareprodukt eine konkrete Nische bedienen und kaum international tätig sind, sehr gering. Aber, dem geringen Eintrittsrisiko steht wie gesagt ein großer potentieller Schaden entgegen.
Im Falle von Unternehmenstransaktionen ist eine Kernfunktion des Kaufvertrags immer auch, eine Risikoallokation zwischen Verkäufer und Käufer vorzunehmen. Und so wird stets auch das Risiko einer Open Source Lizenzverletzung adressiert.
Perspektive des Käufers: Open Source Lizenz Compliance
Ein Käufer eines Software-Unternehmens möchte zugesichert bekommen, dass die Software - in den meisten Fällen das zentrale wertbildende Element des Unternehmens - in einer Art und Weise entwickelt wurde, die sämtliche Lizenzbedingungen eingesetzter Software-Komponenten beachtet und einhält. Üblicherweise wird sich dies in einer Garantie im Kaufvertrag wiederfinden, die unterschiedlich weit gestaltet werden kann. Da das sehr hypothetische Szenario, dass ein Open Source Lizenzverstoß von einem Urheber identifiziert wird, dazu führen kann, dass die gesamte Software nun nicht mehr vertrieben werden kann, hat der Käufer das Interesse, die Haftungsgrenze für diesen Garantiefall möglichst hoch zu legen, üblicherweise bei mindestens 100% des ausgehandelten Kaufpreises.
Perspektive des Verkäufers: Geringes Risiko, keine Garantie
Einen 100%-igen Überblick, welche Open Source Bibliotheken genau genutzt werden, gibt es in den meisten Unternehmen nicht. Ein Geschäftsführer / Gesellschafter wird sich in diesem Fall auch schwer tun, eine Garantie darauf abzugeben, dass keine Open Source Lizenzen verletzt werden. Gleichzeitig ist das Risiko sehr schwer greifbar (da extrem hypothetisch) - eine hohe Haftungsgrenze wirkt abschreckend und eine lange Verjährungsfrist ermöglicht es dem Verkäufer nicht, mit dem Unternehmen “abzuschließen”. Je geringer das Vertrauen in das eigene Compliance System, desto geringer die Bereitschaft, eine harte Garantie hierauf abzugeben. Das Ganze wird zudem in vielen Fällen erschwert, als dass der Verkäufer Gespräche über die Transaktion vor seinen Mitarbeitern geheim halten möchte und somit auch nicht bei seinen Software-Entwicklern aktiv nachfragen möchte, wie es um die Open Source Compliance bestellt ist.
Zusammenführung: Open Source Audit / Open Source Scan
Da sich bei zwei so konträren Positionen die Risikoallokation im Kaufvertrag oftmals zum Problem entwickelt, ist es in vielen Fällen die einzige Lösung, einen Open Source Audit / Open Source Scan durchführen zu lassen. In diesem Fall wird ein externer Dienstleister beauftragt, den Source-Code zu scannen, Open Source Komponenten und ggf. Lizenzverstöße zu identifizieren.
Es gibt eine Vielzahl von Dienstleistern, die Open Source Scans anbieten. Da diese Scans oftmals kurzfristig während einer Transaktion bereitgestellt werden müssen, rufen die Anbieter jedoch Kosten auf, die sich üblicherweise im Bereich von 15.000€ - 50.000€ bewegen. Umfang und Qualität des Scans sind stark unterschiedlich. So wird von einigen Anbietern berichtet, dass die Scans eine Tendenz haben übermäßig viele kritische Komponenten zu identifizieren (zu viele “false positives”), während andere Anbieter beim Scan gelegentlich auch Bibliotheken auslassen. Grundsätzlich sind die meisten Anbieter dazu übergegangen, den reinen Scan auch mit einer Dienstleistung zu verknüpfen, also ein internes Team bereitzustellen welches den Audit qualitativ begleitet. So werden die Scan-Ergebnisse einer manuellen Überprüfung unterzogen, die ein höheres Qualitätsniveau sicherstellen soll.
Skepsis bleibt jedoch stets bestehen, sodass der grundsätzliche Sinn & Zweck des Open Source Scans hauptsächlich ist, dass Käufer und Verkäufer einen “externen” Blick auf die verwendeten Open Source Bibliotheken und die assoziierten Lizenzen bekommen und sich somit hinsichtlich einer konkreten Einschätzung des Risikos eine zielführende Diskussion ergeben kann.
Eine nicht-abschließende Liste von Anbietern von Open Source Scan / Open Source Audits:
Black Duck / Synopsys: www.blackducksoftware.com
Whitesource: www.whitesourcesoftware.com
Sonatype: www.sonatype.com
Flexera: www.flexera.com
FOSSID: www.fossid.com
EACG / Trustsource: www.trustsource.io
Veracode: www.veracode.com
Open Source Regelungen in der Praxis
Einzelne Aspekte / Garantien des Kaufvertrags werden immer im Gesamtpaket gesehen, weshalb es nicht möglich ist, eine pauschale Herangehensweise zu skizzieren.
Einigt man sich darauf, dass eine entsprechende Garantie in den Kaufvertrag aufgenommen wird, kann diese unterschiedlich scharf formuliert werden. Es kann entweder der faktische Zustand “keine Lizenzverletzung” oder aber der Prozess dahin garantiert werden. Eine Kompromisslösung, die eher Verkäuferfreundlich ist, kann beispielsweise so aussehen:
“Der Verkäufer hat sich mit der erforderlichen Sorgfalt und unter Anwendung geeigneter organisatorischer und technischer Maßnahmen fortlaufend darüber vergewissert, dass der Geschäftsbetrieb der Gesellschaft keine gewerblichen Schutzrechte Dritter verletzt und dass die Gesellschaft von Dritten stammende Softwarekomponenten im Einklang mit den jeweils dafür geltenden Lizenzbestimmungen verwendet.”
Liegt kein Open Source Scan vor, können sich Verkäufer und Käufer auch darauf einigen, einen Open Source Scan direkt nach Unterzeichnung des Kaufvertrags durchführen zu lassen und mögliche Lizenzverstöße im Anschluss direkt zu beheben. Die Kosten für den Scan und das anschließende Beheben (Programmiertätigkeit) trägt hierbei üblicherweise der Verkäufer, wobei auch vereinbart werden kann, dass der Käufer die Kosten trägt, sofern keine gravierenden Lizenzverstöße im Scan entdeckt werden (auch möglich: Kostenteilung).
Grundsätzlich gibt es hinsichtlich der vertraglichen Ausgestaltung wie immer eine große Flexibilität. Zwischen Käufer und Verkäufer existiert stets eine Informationsasymmetrie. Der Verkäufer kann die Risiken seines Unternehmen aber meist besser einschätzen. Der Bereich Open Source Lizenz-Compliance stellt hier jedoch einen Sonderfall dar, da vielen Unternehmern in diesem Bereich die Brisanz des Themas bis zum Zeitpunkt der Transaktion / Due Diligence nicht bewusst war. Somit ist eine Risikoallokation ohne eine externe objektive Einschätzung via Open Source Scan im Kaufvertrag schwierig. Dieser kann dann aber - auch wenn durchaus beachtenswerte Kosten entstehen - dazu beitragen, dass sich Verkäufer und Käufer auf eine ausgewogene Gestaltung im Garantiekatalog einigen können.