Open Source Due Diligence: Wer sucht wird fündig

28.04.2016 – Wer ein Software-Unternehmen kauft, sollte die Open Source Bestandteile überprüfen. Fast immer ergeben sich dabei Erkenntnisse, die sich auf Kaufpreis oder Vertragsgestaltung auswirken. Umgekehrt sollte jedes Software-Unternehmen seine Schwachstellen finden, bevor es der Käufer tut. 

Was ist eine Open Source Due Diligence?

Beim Unternehmenskauf ist die Due Diligence-Prüfung durch den Käufer ein Standardvorgang. Der Bereich IP (Intellectutal Property) verdient besondere Betrachtung, wenn Software einen wesentlichen Teil des Geschäftszwecks bildet. Open Source Software spielt dabei fast immer eine Rolle und ist eine fast sichere Ursache für unerwartete Findings. Stellt sich bei der Open Source Due Diligence heraus, dass die Software, die möglicherweise schon an Kunden ausgeliefert wurde, gegen Lizenzbedingungen verstößt, entstehen Rückstellungserfordernisse mit Auswirkungen auf den bisher anvisierten Kaufpreis. Latente Probleme, bei denen man getrost auf die Nichtentdeckung vertrauen konnte, werden zu akuten Belastungen für den Verkäufer. 

Wie läuft eine Open Source Due Diligence ab?

Typischerweise wird zunächst auf technischer Ebene ermittelt, welche Open Source Komponenten zum Einsatz kommen. Wir prüfen die Einhaltung der Lizenzbedingungen anhand der Software-Architektur und die Einhaltung der formalen Erfordernisse, insbesondere die Weitergabe von Pflichtangaben und Source Codes. Im nächsten Schritt kann mit dem Target ermittelt werden, ob und mit welchem Aufwand gefundene Mängel behoben werden können. Für verbleibende Restrisiken wird dann entweder eine Haftungsfreistellung in den SPA (Sales an purchase Agreement) aufgenommen, die Nachbesserung vereinbart oder der Kaufpreis angepasst.


Im Einzelnen: 

Die Ermittlungen der eingesetzten Software-Komponenten erfordern in der Regel einen maschinellen Scan. Hier kommen entweder kommerzielle Tools wie beispielsweise Black Duck, Palamida oder Open Logic zum Einsatz, die jede Codezeile auf Übereinstimmungen mit bekannten Source Codes überprüft. Eine günstigere, aber weniger präzise Methode ist die Durchsuchung der Codebase nach Lizenzhinweisen mit Programmen wie beispielweise FOSSology, Scancode oder selbstgeschriebener Software. 

In vielen Fällen überprüfen wir Source Codes auch manuell auf Hinweise und recherchieren typische abhängige Komponenten über öffentliche Repositories (Github, Sourceforge). Dort wo nur Binärcode zur Verfügung steht, der nicht mit ausreichender Sicherheit überprüft werden kann, werden Garantien vereinbart. 

Die erste BOM (Bill of Material) enthält häufig hunderte von auf dem ersten Eindruck kritischen Treffern. Bei näherer Analyse ergibt sich manchmal, dass Softwarekomponenten zwar Teil der Codebase sind, letztlich jedoch nicht im Build-Prozess benötigt werden und somit auch nicht weitergegeben werden. Hier ist eine intensive Mitwirkung des Targets oder technischer Gutachter erforderlich. Soweit an dieser Stelle Erklärungen nicht von uns selbst validiert werden können, finden Sie Eingang in die Garantieerklärungen. Das Vorhandensein von Komponenten unter strengen Lizenzen mit Copyleft wie z. B. GPL oder EPL bedarf einer weiteren Aufklärung. Hier geht es um die Frage, ob die Verknüpfung mit eigenem Source Code ohne eine Codefreigabe zulässig ist. Wir prüfen hier, ob so genanntes „Derivative Work“ vorliegt. Bei Lizenzen mit beschränktem Copyleft (LGPL, MPL) kommt es auf die Art der Einbindung und die Austauschbarkeit an. Das Problem der Tivoisierung betrifft dabei nicht erst GPL 3.0 lizenzierte Software, sondern gerade auch LGPL-Software bei Verbindung mit proprietärem Code. 

Unterschiedliche Intensität der Due Diligence Prüfungen 

Die Intensität, Genauigkeit und damit auch die Dauer der Prüfung hängt von den Vorgaben des Auftraggebers ab. 

  1. In der einfachsten Form werden lediglich Angaben ohne nähere Überprüfung plausibilisiert und in den Garantiekatalog aufgenommen. Unser Anteil an den Vertragsverhandlungen beschränkt sich dann auf wenige Interviews und die Beisteuerung von Vertragsklauseln. 
  2. Wenn man zuverlässig wissen möchte, welche Open Source Komponenten in einer Software vorhanden sind und unter welcher Lizenz sie stehen, muss die Codebase analysiert werden. In Betracht kommen dabei drei Methoden:
  3. Manuelle Überprüfung der Source Code Dateien auf Copyright-Hinweise
    1. Automatisierter Scan auf Copyright-Hinweise, Lizenztexte und andere vorgegebene Suchbegriffe mit Open Source basierten Tools
    2. Ausführliche Analyse über kommerzielle Tools, wie z. B. Palamida, Black Duck Protex, Open Logic u.a. auf partielle Codeübernahmen aus öffentlichen Repositories 

Jeder Ansatz hat seine Vor- und Nachteile im Hinblick auf Kosten, Genauigkeit und Aufwand. Wir könnten auch die technischen Analysen für Sie erbringen oder koordinieren. Header-basierte manuelle oder automatisierte Analysen erbringen wir im Haus mit eigenen Tools; kommerzielle Scans können Sie entweder direkt bei den jeweiligen Anbietern beauftragen, oder auch über unsere Kanzlei abwickeln.

Der zeitliche Aufwand für die Analyse von Codebases wird immer wieder unterschätzt. Der Vorgang ist nur auf dem ersten Blick mit der Benutzung eines Virenscanners vergleichbar. Die Scanner werfen häufig für jede Source Code Datei ein Ergebnis aus, das beurteilt und weiter verarbeitet werden muss. Manchmal wird die Suche auf kritische Lizenzen beschränkt, wenn jedoch vollständige Pflichtangaben für eine legale Weitergabe der Software ermittelt werden sollen, müssen Lizenzhinweise vollständig ausgewertet werden. 

Die Beurteilung der Lizenzeinhaltung kann nicht alleine auf Grundlage der Codebase vorgenommen werden, sondern erfordert auch Angaben des Entwicklerteams. Das beginnt bei der Fragestellung, ob eine Datei Eingang in das kompilierte Endprodukt findet oder ohne Auswirkungen auf das Target entfernt werden könnte. Komplizierter wird es bei den Fragestellungen zur Verlinkung. Wenn Lizenzen mit Copyleft-Effekt mit proprietär lizenziertem Code verbunden werden, hängt die Verpflichtung zur Freigabe der eigenen Software davon ab, wie die Bestandteile verbunden werden. 

Empfohlenes Vorgehen für den Anfang

Wenn Sie eine schnelle Einschätzung dafür gewinnen wollen, ob und in welcher Dimension rechtliche Probleme aus Open Source Lizenzen bestehen, könnten Sie mit einem eigenen Source Code Scan beginnen. Mit Tools wie FOSSology oder Scancode können Sie eine kleine Codebase mit weniger als 100 MB Datenvolumen innerhalb einiger Stunden durchsuchen. Wenn Sie dabei auf weniger als zehn verschiedene Lizenzen stoßen, die allesamt keinen Copyleft-Effekt vorsehen, können Sie fürs Erste bereits aufatmen. 

Wenn Ihnen jedoch einige hundert Treffer von GPL- und LGPL-artigen Lizenzen angezeigt werden, sollten Sie Ihren Transaktionsfahrplan kritisch daraufhin überprüfen, ob Sie für genauere Analysen ein bis zwei Monate zusätzliche Zeit einkalkulieren können. Natürlich können Sie alternativ dazu auch mit vertraglichen Freistellungsvereinbarungen arbeiten, wenn jedoch die zu untersuchende Software und deren Vermarktbarkeit wesentlicher Bestandteil des Geschäftsmodels sind, werden Ihnen Garantiezusagen möglicherweise nicht ausreichen. 

Wie sehen vertragliche Konsequenzen aus Open Source Findings aus?

Findings im Open Source Bereich können ein lizenzbasiertes Geschäftsmodell zu Fall bringen. Während früher Open Source Software nur im Hinblick auf die fehlende Schützbarkeit untersucht wurde, wird heute die Lizenzeinhaltung als Voraussetzung für die Marktgängigkeit eines Produktes erkannt. Einkäufer von OEMs überprüfen inzwischen mit kommerziellen Scanning Tools zugelieferte Software auf Open Source Inhalte. Rechteinhaber verklagen Soft- und Hardwarehersteller auf Unterlassung der Weitergabe (LG Hamburg VM-Ware) und Mitbewerber ignorieren angebliche Urheberrechte, da sie sich auf Open Source Lizenzen berufen (LG Berlin AVM gegen Cybits). 

Wie wir Ihnen helfen können?

Für eine erste Einschätzung reicht ein Halbtages-Workshop und ein USB-Stick. Auf diesen Grundlagen können wir schon schnell einschätzen, ob und in welcher Dimension rechtliche Probleme zu erwarten sind. Nach einem ersten Scan sieht man bereits, welche Lizenzen verbaut wurden und auf welchem Compliance-Niveau die bisherige Software-Entwicklung stattfand. Ihre Ansprechpartner in unserer Kanzlei sind RA Chan-jo Jun und RAin Yvonne Roßmann.