Open Source und geistiges Eigentum in der Tech Due Diligence: Die versteckten Rechtsrisiken, die erst nach dem Deal sichtbar werden

Das Wichtigste in Kürze Die meisten technischen Due-Diligence-Prüfungen konzentrieren sich auf Architektur, Codequalität, Sicherheit und Team. Das geistige Eigentum an der Software kommt dabei oft zu kurz, denn es liegt genau zwischen dem technischen und dem rechtlichen Prüfungsstrang, und keiner von beiden fühlt sich vollständig dafür zuständig. Dabei gehören IP-Probleme zu den teuersten Überraschungen nach dem Closing: eine Copyleft-Lizenz in einem Kernmodul, Code von Freelancern ohne wirksame Rechteeinräumung oder ein wachsender Anteil KI-generierten Codes mit unklarem Schutzstatus. Dieser Beitrag zeigt, wo diese Risiken typischerweise stecken, wie Sie sie in der Due Diligence prüfen und wie Sie Befunde in Vertragsbedingungen übersetzen, statt sie erst bei der Integration zu entdecken.

Warum IP-Risiken einen eigenen Prüfungsstrang verdienen

Bei einer typischen Transaktion prüft die Rechtsberatung Verträge, Marken und Patente, während das technische Team die Codebasis bewertet. Genau in der Lücke zwischen beiden liegen die Software-IP-Risiken. Juristinnen und Juristen analysieren selten Abhängigkeitsbäume, und Entwicklerinnen und Entwickler lesen selten Arbeits- oder Dienstverträge.

IP-Befunde unterscheiden sich von den meisten technischen Themen vor allem durch ihren Zeitpunkt und ihre Tragweite. Technische Schulden bremsen die Roadmap; ein IP-Mangel kann dagegen genau den Vermögenswert beschädigen, für den Sie bezahlt haben. Typische Folgen sind:

• die erzwungene Offenlegung proprietären Quellcodes unter einer Copyleft-Lizenz,
• aufwendiges Re-Engineering, weil eine Komponente nicht kommerziell genutzt werden darf,
• Streitigkeiten mit ehemaligen Freelancern oder Gründern über die Rechte am Code,
• Verletzungen des Garantiekatalogs im Kaufvertrag, die lange nach Zahlung des Kaufpreises zu Ansprüchen führen.

Solche Probleme zeigen sich selten in den ersten Wochen nach dem Closing. Meist treten sie auf, wenn der Käufer etwas Neues vorhat: einen Konzernkunden mit strengem Einkaufsprozess gewinnen, den nächsten Exit vorbereiten oder das Produkt in eine größere Plattform integrieren.

Open-Source-Lizenz ist nicht gleich Open-Source-Lizenz

Nahezu jedes moderne Softwareprodukt basiert zu einem großen Teil auf Open Source. Das ist an sich kein Problem. Das Risiko hängt davon ab, welche Lizenzen verwendet werden, wie der Code eingesetzt wird und wie das Produkt vertrieben wird.

Zwei Punkte werden in der Praxis häufig missverstanden.

Erstens deckt die sogenannte „SaaS-Lücke“ nicht alles ab. Viele Teams gehen davon aus, dass GPL-Pflichten nie greifen, weil sie keine Software weitergeben. Für die GPL in einem reinen SaaS-Modell trifft das weitgehend zu, nicht jedoch für die AGPL. Ebenso wenig gilt es für Komponenten, die an Kunden ausgeliefert werden, etwa On-Premise-Installationen, mobile Apps, Desktop-Clients, SDKs oder Embedded-Firmware. Gerade im industriellen Mittelstand in Deutschland und Österreich, wo Software häufig in Maschinen und Anlagen steckt, ist dieser Punkt besonders relevant.

Zweitens ändern sich Lizenzen im Laufe der Zeit. Mehrere verbreitete Infrastrukturprojekte sind in den letzten Jahren von Open Source auf restriktivere Source-available-Lizenzen umgestiegen; der Wechsel von HashiCorp zur Business Source License im Jahr 2023 ist ein bekanntes Beispiel. Eine Abhängigkeit, die bei ihrer Einführung unproblematisch war, kann in der aktuellen Version ganz andere Bedingungen mit sich bringen.

Wo die Risiken tatsächlich stecken

Eine saubere Liste der direkten Abhängigkeiten bedeutet noch keine saubere Codebasis. Nach unserer Erfahrung stammen die wesentlichen Befunde meist aus weniger offensichtlichen Quellen.

Transitive Abhängigkeiten. Eine permissiv lizenzierte Bibliothek kann ihrerseits Komponenten mit deutlich restriktiveren Bedingungen nachladen. Ohne Analyse des vollständigen Abhängigkeitsbaums bleiben diese unsichtbar.

Kopierte Code-Snippets. Code aus öffentlichen Repositories, Foren oder Tutorials taucht in keinem Paketmanifest auf. Ihn aufzuspüren erfordert einen Scan auf Snippet-Ebene, nicht nur eine Manifestanalyse.

Eingebettete und geforkte Bibliotheken. Direkt ins Repository kopierte und oft vor Jahren angepasste Bibliotheken verlieren ihre sichtbare Verbindung zum Ursprungsprojekt und dessen Lizenz.

Kommerzielle Komponenten. Kostenpflichtige Bibliotheken, SDKs, Schriften und Datensätze unterliegen eigenen Lizenzbedingungen. Manche sind an eine bestimmte Gesellschaft, Nutzerzahl oder Bereitstellungsform gebunden und überstehen einen Kontrollwechsel (Change of Control) unter Umständen nicht ohne Nachverhandlung.

Fehlende Lizenzhinweise. Auch permissive Lizenzen verlangen eine Namensnennung. Fehlende Hinweisdateien lassen sich meist leicht nachholen, sie sagen aber viel über die Reife der Compliance-Prozesse insgesamt aus.

Wem gehört der Code eigentlich?

Open Source ist nur die eine Hälfte des Bildes. Die andere Hälfte ist die Frage, ob das Zielunternehmen tatsächlich über die Rechte an seinem selbst entwickelten Code verfügt. Lücken bei der Rechtekette sind in schnell wachsenden Unternehmen verbreitet, insbesondere wenn Freelancer, Agenturen oder Gründer vor der Gesellschaftsgründung am Code gearbeitet haben.

Dabei ist ein Punkt für Käufer aus Deutschland und Österreich wichtig: Das Urheberrecht selbst ist in beiden Ländern nicht übertragbar. Übertragen werden können nur Nutzungsrechte (in Österreich: Werknutzungsrechte bzw. Werknutzungsbewilligungen). Die entscheidende Frage lautet also nicht „Gehört der Code dem Unternehmen?“, sondern „Verfügt das Unternehmen über ausschließliche, zeitlich und räumlich unbeschränkte Nutzungsrechte in dem Umfang, den das Geschäftsmodell erfordert?“

Für die Prüfung sind vor allem folgende Fragen relevant:

• Angestellte: Für Computerprogramme, die Arbeitnehmer in Wahrnehmung ihrer Aufgaben schaffen, erhält der Arbeitgeber nach § 69b UrhG (Deutschland) bzw. § 40b UrhG (Österreich) grundsätzlich die vermögensrechtlichen Befugnisse, sofern nichts anderes vereinbart ist. Zu prüfen ist, ob der Code tatsächlich im Rahmen der Arbeitsaufgaben entstanden ist und ob es abweichende Vereinbarungen gibt.
• Freelancer und Dienstleister: Hier greift keine gesetzliche Zuordnung. In Deutschland gilt zudem die Zweckübertragungslehre (§ 31 Abs. 5 UrhG): Im Zweifel werden nur die Rechte eingeräumt, die für den Vertragszweck erforderlich sind. Unklar formulierte Verträge führen daher schnell zu einem zu engen Rechteumfang, etwa ohne Recht zur Bearbeitung, Unterlizenzierung oder Weiterübertragung an einen Erwerber.
• Gründer: Wurde Code, der vor der Gründung der Gesellschaft entstanden ist, wirksam in die Gesellschaft eingebracht?
• Agenturen und Softwarehäuser: Räumen die Verträge ausschließliche Nutzungsrechte ein oder lediglich eine einfache Lizenz?
• Förderprojekte und Hochschulkooperationen: Gibt es Verträge, die Dritten Rechte an Teilen der Technologie sichern?

Besonders relevant ist dieser Punkt bei grenzüberschreitenden Teams. Viele Unternehmen aus der DACH-Region arbeiten mit Entwicklerinnen und Entwicklern in Polen, oft auf Basis von B2B-Verträgen. Nach polnischem Recht gehen die Rechte an Software, die ein B2B-Auftragnehmer erstellt, nicht automatisch auf den Auftraggeber über. Eine wirksame Übertragung erfordert einen schriftlichen Vertrag, der die einzelnen Nutzungsarten (pola eksploatacji) ausdrücklich benennt. Dies ist einer der häufigsten und am leichtesten übersehenen Befunde bei Transaktionen mit Nearshoring-Bezug.

KI-generierter Code: Eine neue Kategorie von IP-Risiken

Im Jahr 2026 gibt es kaum noch Entwicklungsteams, die ohne KI-Coding-Assistenten arbeiten. Damit entstehen Fragen, die vor wenigen Jahren in keiner Due-Diligence-Checkliste standen.

Der urheberrechtliche Schutz kann eingeschränkt sein. Sowohl in Deutschland als auch in Österreich setzt Urheberrechtsschutz eine menschliche geistige Schöpfung voraus. Rein KI-generierte Inhalte sind daher in der Regel nicht geschützt, während menschliche Beiträge wie Auswahl, Anordnung und wesentliche Überarbeitung durchaus Schutz begründen können. Für die meisten Produkte ist das kein akutes Problem, da Entwickler KI-Vorschläge prüfen, anpassen und integrieren. Kritisch wird es dort, wo größere, in sich geschlossene Module weitgehend ohne menschliche Gestaltung entstanden sind. Denn was nicht geschützt ist, kann auch ein Wettbewerber verwenden.

Vorschläge können lizenzierten Code reproduzieren. KI-Werkzeuge geben gelegentlich Code aus, der stark mit ihren Trainingsdaten übereinstimmt, einschließlich Code unter Copyleft-Lizenzen. Viele Enterprise-Tools bieten Filter, die solche Übereinstimmungen mit öffentlichem Code blockieren, allerdings nur, wenn sie aktiviert sind.

Nutzungsbedingungen und Datenverarbeitung unterscheiden sich. Verbraucherversionen von KI-Tools haben häufig andere Bedingungen in Bezug auf die Rechte am Output und die Verwendung eingegebener Daten als Enterprise-Tarife. Wurden proprietärer Code oder Kundendaten in nicht freigegebene Tools eingegeben, kann dies zusätzlich Fragen zu Geheimnisschutz und DSGVO aufwerfen.

Bei der Bewertung eines Zielunternehmens geht es daher nicht um die Frage, ob das Team KI nutzt, sondern ob es KI kontrolliert und nachvollziehbar nutzt. Achten Sie auf:

• eine Liste freigegebener KI-Tools mit Enterprise-Bedingungen,
• aktivierte Filter gegen Übereinstimmungen mit öffentlichem Code,
• eine schriftliche Richtlinie, welcher Code und welche Daten mit KI-Tools geteilt werden dürfen,
• Review-Standards, die für KI-gestützten und manuell geschriebenen Code gleichermaßen gelten.

Ein Team, das diese Fragen souverän beantwortet, verfügt in der Regel auch insgesamt über eine reife Engineering-Kultur. Ein Team, das hier keine klaren Antworten hat, weist häufig auch an anderer Stelle Lücken auf. Wie sich solche Regeln in der Praxis umsetzen lassen, beschreiben wir auf unserer Seite zur KI-gestützten Softwareentwicklung.

So prüfen Sie IP-Risiken in der Due Diligence

Eine wirksame IP-Prüfung kombiniert automatisierte Analysen mit Dokumentenprüfung und gezielten Interviews. In der Praxis hat sich folgendes Vorgehen bewährt.

1. Eine Software-Stückliste (SBOM) erstellen. Mit Werkzeugen zur Software Composition Analysis (SCA) entsteht ein vollständiges Verzeichnis direkter und transitiver Abhängigkeiten einschließlich ihrer Lizenzen. Standardformate wie SPDX oder CycloneDX machen die Ergebnisse wiederverwendbar. Das ist bald nicht mehr nur für M&A relevant: Der EU Cyber Resilience Act führt SBOM-bezogene Pflichten für Produkte mit digitalen Elementen ein, deren Großteil ab Dezember 2027 gilt. Unternehmen, die Lizenzscans und SBOM-Erstellung fest in ihre CI/CD-Pipelines und ihren Cloud-Betrieb integrieren, sind auf beides deutlich besser vorbereitet.

2. Kritische Repositories auf Snippet-Ebene scannen. Konzentrieren Sie sich auf das Kernprodukt, nicht auf jedes interne Hilfswerkzeug. Ziel ist es, kopierten Code ohne Lizenzangabe zu finden.

3. Lizenzen dem Vertriebsmodell gegenüberstellen. Dieselbe Lizenz kann in einem Backend-Dienst unbedenklich und in einer mobilen App oder einer On-Premise-Installation hochproblematisch sein. Befunde müssen immer im Kontext bewertet werden.

4. Die Rechtekette dokumentarisch prüfen. Gleichen Sie die Commit-Historie mit der Liste der Angestellten und Auftragnehmer ab, für die wirksame Rechteeinräumungen vorliegen. Personen, die im Code auftauchen, aber nicht in den Vertragsunterlagen, sind ein sofortiges Warnsignal.

5. Kommerzielle Lizenzen auf Change-of-Control-Klauseln prüfen. Identifizieren Sie Komponenten, deren Lizenz bei einem Erwerb endet oder eine Zustimmung des Lizenzgebers erfordert.

6. KI-Nutzung und Governance bewerten. Führen Sie Gespräche mit den technischen Verantwortlichen, prüfen Sie die Tool-Konfigurationen und klären Sie, ob eine KI-Richtlinie existiert und tatsächlich gelebt wird.

Von Befunden zu Vertragsbedingungen

Nicht jeder Befund ist ein Dealbreaker. Ziel der IP-Due-Diligence ist keine perfekte Codebasis, sondern ein angemessener Kaufpreis und ein wirksamer Schutz. Die Befunde lassen sich in der Regel drei Gruppen zuordnen.

Geringe Schwere: nach dem Closing beheben. Fehlende Lizenzhinweise, veraltete Lizenzdateien und kleinere Lücken bei permissiven Lizenzen. Diese gehören in den 100-Tage-Plan.

Mittlere Schwere: vor dem Closing beheben oder im Preis berücksichtigen. Komponenten mit schwachem Copyleft, deren Einbindung Pflichten auslösen könnte, nachzuverhandelnde kommerzielle Lizenzen oder fehlende Rechteeinräumungen einzelner ehemaliger Freelancer. Typische Instrumente sind Closing-Bedingungen, spezifische Freistellungen und die Einpreisung geschätzter Behebungskosten.

Hohe Schwere: berührt die Investitionsthese. Code mit starkem oder Netzwerk-Copyleft in proprietären Kernmodulen eines ausgelieferten Produkts oder wesentliche Teile der Codebasis mit ungeklärter Rechtelage. Solche Befunde können eine deutliche Kaufpreisanpassung, einen Treuhandeinbehalt (Escrow), erweiterte Garantien, eine Berücksichtigung bei der W&I-Versicherung oder im Extremfall den Abbruch der Transaktion rechtfertigen. Zu beachten ist dabei, dass W&I-Versicherer bekannte Risiken aus der Due Diligence in der Regel ausschließen; umso wichtiger sind dann spezifische Freistellungen.

Entscheidend ist, den Behebungsaufwand zu beziffern: Wie viele Entwicklerwochen würde es kosten, eine problematische Komponente zu ersetzen, ein Modul neu zu implementieren oder fehlende Rechteeinräumungen einzuholen? Diese Schätzung macht aus einem abstrakten Rechtsrisiko eine Zahl, über die beide Seiten verhandeln können. Erfordert die Behebung den Umbau größerer Teile des Produkts, hilft ein AI Refactoring Assessment, den Aufwand bereits vor der Unterzeichnung realistisch einzuschätzen. Die Umsetzung selbst lässt sich im Rahmen der laufenden Produkt- und Anwendungsentwicklung planen, ohne die Roadmap anzuhalten.

Saubere Rechte sind Teil des Kaufgegenstands

Käufer zahlen für Software, weil sie erwarten, sie uneingeschränkt nutzen und weiterentwickeln zu können. Ist die Rechtelage unklar oder schränken Lizenzen künftige Pläne ein, existiert ein Teil dieses Werts schlicht nicht. Die gute Nachricht: Die meisten IP-Probleme lassen sich vor der Unterzeichnung erkennen, und viele davon sind kostengünstig zu beheben, wenn sie früh entdeckt werden.

Am wirksamsten ist ein Vorgehen, das IP als gemeinsamen technischen und rechtlichen Prüfungsstrang behandelt, gestützt auf automatisierte Scans, Vertragsprüfung und einen ehrlichen Blick darauf, wie das Team KI einsetzt. Für Verkäufer ist dieselbe Prüfung einer der einfachsten Wege, den Unternehmenswert zu sichern, bevor die Due Diligence des Käufers beginnt. Wenn Sie eine Transaktion oder einen Exit vorbereiten, erfahren Sie auf unserer Seite zur technischen Due Diligence, wie wir dabei vorgehen.

Dieser Beitrag dient ausschließlich der allgemeinen Information und stellt keine Rechtsberatung dar. Lizenz- und Rechtefragen sollten stets mit einer qualifizierten Rechtsberatung in der jeweiligen Rechtsordnung geklärt werden.

‍