Open Source als Deal-Faktor

Aus Käuferperspektive stehen zwei Fragen im Fokus: Welche Rechte gehen am Technologie-Stack über und welche Verpflichtungen und Risiken erwerbe ich mit? Unklare Lizenzlagen, fehlende Dokumentation oder Copyleft-Verstöße können zu Nachlizenzierungen, Offenlegungspflichten oder Unterlassungsansprüchen führen und den Wert der Software-Assets sowie die Integrationsstrategie beeinträchtigen. Aus Verkäufersicht erhöht ein lückenlos dokumentierter und lizenzkonformer OSS-Einsatz die Glaubwürdigkeit der technischen Darstellung und reduziert das Risiko von Preisabschlägen.

Die typischen Risikofelder

OSS ist in modernen Softwarearchitekturen unerlässlich, auch in Hardware eingebettete Komponenten sind betroffen. Die Nutzung bringt spezifische Risiken mit sich. Um diese zu erkennen und zu steuern, ist die Berücksichtigung typischer Risikofelder essenziell.

1. Lizenzen & Copyleft-Exposition
   Nicht alle OSS-Lizenzen sind gleich: Permissive Lizenzen wie MIT, BSD oder Apache erzeugen meist überschaubare Pflichten, während Copyleft-Lizenzen wie GPL oder AGPL bei statischer oder bestimmter dynamischer Kopplung Offenlegungspflichten auslösen können. Der Copyleft-Effekt bedeutet, dass Veränderungen eines Werks unter derselben Lizenz veröffentlicht werden müssen. Im Worst Case müssten dadurch proprietäre, wertbildende Software-Assets offengelegt werden. Auch Beschränkungen der kommerziellen Nutzung sind zu beachten, insbesondere Creative-Commons-Lizenzen untersagen oder beschränken diese häufig.
2. Dokumentation & SBOMs
   Oft ist die Dokumentation der eingesetzten Open-Source-Komponenten unvollständig. SBOMs (Software Bill of Materials) existieren nicht oder sind lückenhaft. Dadurch sind Lizenz- und Sicherheitsrisiken schwer einschätzbar und realisieren sich häufig in der Integrationsphase.
3. IP-Clearance & Contributor Rights
   Zu prüfen ist die Herkunft des Codes: Liegen CLAs (Contributor License Agreements) oder anderweitige, rechtlich belastbare Rechteübertragungen vor und sind diese dokumentiert – insbesondere bei externen Partnern und Community-Contributions? Fehlt eine lückenlose Rechtekette, bestehen Unterlassungs- oder Nachlizenzierungsrisiken, die zentrale Module und Funktionen gefährden ­können?
4. Governance & Prozessreife
   Gibt es ein OSPO (Open Source Program Office) oder klare Richtlinien, die Einsatz und Freigabe von OSS, Lizenzprüfungen, Schwachstellenmanagement, Dokumentation und Community-Engagement steuern? Ausgereifte Prozesse sind ein Indikator für niedrige Deal-Risiken und ermöglichen risikoorientierte Entscheidungen.

OSS-Due-Diligence: Key Factors

Eine wirkungsvolle Prüfung ist zielgerichtet und risikoorientiert. Sie verbindet forensische Code-Analyse mit rechtlicher Bewertung und kommerzieller Einordnung. Der Scope orientiert sich an der Relevanz für das Zielproduktportfolio und die maßgeblichen Werttreiber.

1. Datenvalidierung als Grundlage
   Am Anfang steht die vollständige Identifikation und technische Validierung der OSS-Komponenten: Toolgestützte Scans (inklusive Lizenzen, Snippets, Abhängigkeiten) werden mit Entwickler-Interviews, Repository-Reviews und SBOM-Checks kombiniert.
2. Rechtliche Analyse
   Identifizierte Komponenten werden auf Lizenzen, Kompatibilität, Offenlegungspflichten und Einschränkungen geprüft. Von zentraler Bedeutung ist, wer an welchen Software-Assets welche Rechte hält. Proprietäre Software wird gemeinsam mit den OSS-Komponenten betrachtet. Ausgehend von Beschreibungen der wertbildenden Assets und Interviews wird geprüft, ob die Rechte exklusiv beim Unternehmen liegen und kommerziell verwertet werden können. Es wird geprüft, wer an der Entwicklung beteiligt war und wie Rechte vertraglich gesichert sind (etwa in Arbeits-, Freelancer- oder Software-Entwicklungsverträgen).
3. Kommerzielle Einordnung
   Die kommerzielle Einordnung antizipiert Effekte auf Kaufpreis, Deal-Struktur, Integrationsaufwand und zukünftigen Revenue und quantifiziert sie idealerweise.

Verkäufer: Den Deal sichern durch Offenheit und Vorbereitung

Wer sich früh mit Open Source auseinandersetzt, verbessert seine Verkaufschancen. Ein Gesundheitscheck der eingesetzten OSS und der Risikofelder – idealerweise 6 bis 9 Monate vor dem geplanten Verkauf – erhöht die Transparenz, reduziert Risiken und steigert die Deal-Readiness. Die Bereitstellung gut aufbereiteter SBOMs, Lizenzhinweise, Architekturdokumentationen sowie Informationen zu Prozessen signalisiert den Käufern Verlässlichkeit. Das führt zu transparenten Datenräumen, beschleunigten Due-Diligence-Prozessen, geringeren unerwarteten Risiken und einer stärkeren Verhandlungsposition.

Käufer: OSS-Due-Diligence systematisch angehen

Käufer sollten Open Source strukturiert prüfen und kritische Themen mit klaren Eskalationskriterien priorisieren. Red Flags sind Copyleft-Exposition, Einschränkungen der kommerziellen Nutzbarkeit des Kern-IP und fehlende Rechteketten. Bei relevanten Findings sind belastbare Mitigationsmaßnahmen – vor Signing/Closing oder im Nachgang – sowie passende Garantien und gegebenenfalls Freistellungen erforderlich. Die Mitigation sollte eng mit der technischen Due Diligence erfolgen, um realisierbare Lösungen zu finden (z. B. Austausch kritischer Bibliotheken, Anpassung des Linking-Modells, Lizenzwechsel, kommerzielle Subscriptions). Die kommerzielle Bewertung der Findings ist entscheidend, um Auswirkungen auf den Asset-Wert und den Kaufpreis zu prüfen.

Fazit

Der bewusste Umgang mit Open Source ist eine zentrale Erfolgsgröße für solide Bewertungen, sichere Transaktionen und reibungslose Integration. Open Source ausschließlich defensiv zu betrachten, verschenkt Potenzial. Eine professionelle OSS-Due-Diligence bietet Rechtssicherheit und schafft Mehrwert: Sie liefert belastbare Entscheidungs- und Handlungsoptionen. Sind Copyleft-Exposition und Rechte an den Software-Assets geklärt, SBOMs vollständig und Governance-Modelle vorhanden, steigt die Deal-Readiness. Werden Defizite identifiziert, können sie mitigiert und so ein nachhaltiger Wertbeitrag erzielt werden.

Der Beitrag Open Source bei M&A: Chancen ­erkennen, Risiken managen erschien zuerst auf ManagerWissen.

Der Beitrag Michael Harnisch erschien zuerst auf ManagerWissen.

Der Beitrag Moritz Hagenmüller erschien zuerst auf ManagerWissen.

Der Beitrag ERP als Werthebel in Private Equity erschien zuerst auf ManagerWissen.

Der Beitrag Christian Plath erschien zuerst auf ManagerWissen.

Mitwirkende an dieser Publikation:
Johanna Frey, Binbin Lian Hung, Paul Axmann, Christopher Blegen, Deloitte Consulting

Der Beitrag Marcus Pankow erschien zuerst auf ManagerWissen.