Zum Hauptinhalt springen

M&A-Diligence

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

Wie Verkäufer und Käufer Drittanbieter-Lizenzrisiken in einem Deal bewerten, was ein Lockfile-Dump nicht ist, und wie eine geprüfte Attestationsseite plus Exporte Diligence erfüllen, ohne Last-Minute-Feuerwehr.

Zuletzt aktualisiert: 19. Juli 2026

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 "gut genug" operativer 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 ein einmaliges Spreadsheet zu erfinden.

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

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

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

  • Klären Sie, welche Produkte und Release-Linien im Deal-Scope liegen.
  • Identifizieren Sie Copyleft, Netzwerk-Copyleft und proprietäre SDK-Bedingungen früh.
  • Trennen Sie Sicherheitsfunde von Lizenzoffenlegung. Diligence braucht oft beides, aber es sind nicht dasselbe Deliverable.
  • Fragen Sie, ob der Nachweis an das gebunden ist, was tatsächlich ausgeliefert wird, nicht nur an einen Scan der Marketing-Website.

Wie "gut genug" Nachweis aussieht

Diligence-tauglicher Nachweis ist eine geprüfte Inventarliste für jedes Produkt im Scope, eingefroren bei einem bekannten Publish, mit vollständigem Lizenztext und Attribution, 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.

  • Produktbezogene Inventarliste (direkt und transitiv gemäß Ihrer Policy).
  • Menschlich geprüfte Lizenzkennungen und beigefügter Volltext.
  • 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.
  • Ein Spreadsheet für mehrere Produkte ohne produktbezogenen Scope.
  • Ö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 derselben Schleife, die Sie bereits für Kunden fahren sollten: importieren, was ausgeliefert wird, prüfen, veröffentlichen, dann exportieren. Erfinden Sie keine parallele Diligence-only-Prozess eine Woche vor der Unterzeichnung.

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.

  1. Produkte abgrenzen

    Listen Sie jedes ausgelieferte Produkt im Deal und die Release-Linie, die die Diligence abdeckt.

  2. Importieren und prüfen

    Holen Sie Lockfiles oder SBOMs für diese Releases. Klären Sie needs-review-Zeilen, bevor Sie etwas teilen.

  3. Attestierungsseite veröffentlichen

    Frieren Sie einen Snapshot ein, den Käufer erneut öffnen können. Nennen Sie Produkt und Datum auf der Seite.

  4. 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 Outbound-Distribution 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, Volltext und einen klaren Produkt-Scope. Behandeln Sie das SBOM als Import, und schließen Sie Prüfung und Publish ab, bevor Sie teilen.

Was sollten Verkäufer vor einem Process Letter vorbereiten?

Pro Produkt: eine aktuelle geprüfte Inventarliste, 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 kein einzelnes undatiertes Spreadsheet als vollständig.

Cookies auf sourcetrust.dev

Wir verwenden essenzielle Cookies für die Sicherheit, einschließlich der Missbrauchsprävention bei unserem Website-Scan und dem Anfrageformular für Live-Demos. Mit Ihrer Einwilligung nutzen wir außerdem optionale Analyse und Diagnostik (Google Tag Manager auf dieser Website und das Sentry-Browser-SDK in der SourceTrust-Anwendung, sofern konfiguriert). Siehe unsere Cookie-Richtlinie.