M&A-Diligence

Lizenz-Compliance in M&A: Was Diligence-Teams wirklich brauchen

So bewerten Verkäufer und Käufer das Risiko durch Drittanbieterlizenzen bei einer Transaktion, warum ein Lockfile-Auszug nicht ausreicht und wie eine geprüfte Attestierungsseite mit Exporten die Due Diligence ohne hektische Nacharbeit kurz vor Abschluss unterstützt.

Zuletzt aktualisiert: 19. Juli 2026

Auf dieser Seite

Fusionen und Übernahmen setzen Drittanbieter-Lizenzrisiken unter Zeitdruck. Anwälte, Diligence-Teams und technische Berater müssen wissen, welche Open-Source- und kommerziellen Komponenten in den Produkten des Targets ausgeliefert werden, was jede Lizenz verlangt, und ob der Verkäufer beweisen kann, dass dieser Nachweis aktuell ist.

Dieser Leitfaden ist praxisnah, keine Rechtsberatung. Er beschreibt, wie ein „gut genug“-Nachweis in einem Deal aussieht, die Warnsignale, die den Abschluss verzögern, und wie Sie ein Diligence-Paket zusammenstellen, ohne eine Woche vor der Unterzeichnung eine einmalige Tabelle zu erfinden.

Warum M&A-Anwälte Drittanbieter-Lizenzen ernst nehmen

Lizenzrisiko ist Deal-Risiko. Undeklariertes Copyleft, fehlende Namensnennung oder eine öffentliche Seite, die nicht mehr zum Build passt, können zu Kaufpreiseinbehalten, Preisabschlägen oder Nachbesserungsprogrammen nach dem Closing werden.

Käufer fragen, weil sie die ausgelieferten Produkte und die damit verbundenen Pflichten erben. Verkäufer, die bereits einen geprüften Bestand pflegen, antworten schneller und mit weniger Überraschungen.

Klären Sie, welche Produkte und Release-Linien in den Geltungsbereich des Deals fallen.
Identifizieren Sie Copyleft, Netzwerk-Copyleft und proprietäre SDK-Bedingungen früh.
Trennen Sie Sicherheitsfunde von der Lizenzoffenlegung. Diligence braucht oft beides, aber es sind nicht dieselben Ergebnisse.
Fragen Sie, ob der Nachweis an das gebunden ist, was tatsächlich ausgeliefert wird, nicht nur an einen Scan der Marketing-Website.

Wie ein „gut genug“-Nachweis aussieht

Diligence-tauglicher Nachweis ist ein geprüfter Bestand für jedes Produkt im Geltungsbereich, eingefroren bei einer bekannten Veröffentlichung, mit vollständigem Lizenztext und Namensnennung, wo erforderlich. Eine käuferseitige Attestierungsseite plus passende Exporte sind die übliche Form.

Ein eingefügtes Lockfile, ein ungeprüftes SBOM oder eine NOTICE-Datei von vor drei Jahren ist Input, kein Nachweis. Nachweis bedeutet, dass jemand die Darstellung freigegeben hat, bevor sie das Haus verlassen hat.

Produktbezogener Bestand (direkt und transitiv gemäß Ihrer Richtlinie).
Menschlich geprüfte Lizenzkennungen und beigefügter vollständiger Lizenztext.
Eine stabile URL oder ein Export aus demselben freigegebenen Snapshot.
Eine klare Angabe, welches Release oder Datum der Nachweis abdeckt.

Warnsignale, die Deals verzögern

Die meisten Feuerwehreinsätze beginnen bei denselben Lücken. Erkennen Sie sie, bevor die Data-Room-Anfrage eintrifft.

Keines davon bedeutet, dass der Deal scheitert. Sie bedeuten, dass jemand unter Zeitdruck einen vertretbaren Nachweis neu aufbauen muss.

Undeklarierte oder ungeklärte GPL-, LGPL- oder AGPL-Komponenten in ausgelieferten Builds.
Veraltete NOTICE- oder Attributionsdateien, die nicht zum aktuellen Lockfile passen.
Ein SBOM, das als fertige Offenlegung behandelt wird, ohne geprüften Lizenztext.
Eine Tabelle für mehrere Produkte ohne produktbezogenen Geltungsbereich.
Öffentliche Seiten oder Exporte, die sich nicht auf eine Publish-Freigabe zurückführen lassen.

So erstellen Sie ein Diligence-Paket

Bauen Sie das Paket aus demselben Prozess, den Sie bereits für Kunden verwenden sollten: Importieren Sie, was ausgeliefert wird, prüfen und veröffentlichen Sie es, und exportieren Sie anschließend. Erfinden Sie nicht eine Woche vor der Unterzeichnung einen separaten Due-Diligence-Prozess.

Wenn der Käufer sowohl eine URL als auch Dateien verlangt, generieren Sie beides aus einem eingefrorenen Snapshot, damit der Data Room keine widersprüchlichen Versionen enthält.

Produkte abgrenzen
Listen Sie jedes ausgelieferte Produkt im Deal und die Release-Linie, die die Diligence abdeckt.
Importieren und prüfen
Holen Sie Lockfiles oder SBOMs für diese Releases. Klären Sie prüfungsbedürftige Zeilen, bevor Sie etwas teilen.
Attestierungsseite veröffentlichen
Frieren Sie einen Snapshot ein, den Käufer erneut öffnen können. Nennen Sie Produkt und Datum auf der Seite.
Paket exportieren
Hängen Sie SPDX, CycloneDX, PDF oder NOTICE aus demselben Publish an, wenn der Prozess Dateien verlangt.

Grenzen klar benennen

Eine gepflegte Compliance-Seite und passende Exporte sind Infrastruktur für Diligence, kein Ersatz für Anwälte. Hochrisiko-Lizenzen, Fragen zur ausgehenden Verbreitung und deal-spezifische Freistellungen brauchen weiterhin rechtliche Prüfung.

SourceTrust hilft Teams, den operativen Nachweis aktuell zu halten, damit Anwälte über die wenigen harten Fälle streiten, nicht über fehlende Inventare.

Reicht ein SBOM für M&A-Lizenz-Diligence?

In der Regel nicht allein. Ein SBOM identifiziert Komponenten. Diligence braucht weiterhin geprüfte Lizenzen, vollständigen Lizenztext und einen klaren Produktumfang. Behandeln Sie das SBOM als Import, und schließen Sie Prüfung und Veröffentlichung ab, bevor Sie teilen.

Was sollten Verkäufer vor einem Verfahrensbrief vorbereiten?

Pro Produkt: ein aktueller geprüfter Bestand, eine Attestierungs-URL oder gleichwertige Offenlegung und Exporte aus demselben Snapshot. Zu wissen, welches Release jede Datei abdeckt, spart Tage, wenn der Data Room öffnet.

Was sollten Käufer in der ersten Anforderungsliste verlangen?

Verlangen Sie produktbezogenen Nachweis, gebunden an die Builds im Deal: eine gepflegte Seite oder ein Offenlegungspaket, passende SPDX- oder CycloneDX-Dateien falls erforderlich, und Bestätigung, dass Copyleft-Zeilen geprüft wurden. Akzeptieren Sie keine einzelne undatierte Tabelle als vollständig.

Quellen

Nächster Schritt

Wenn Sie vom Lesen zur Umsetzung übergehen möchten:

Live-Demo anfragen