Open-Source-Lizenz-Audit für vererbte Repos: ein praktischer Plan

Warum vererbte Repositories Lizenzrisiken erzeugen

Wenn ein Repo den Besitzer wechselt, übernehmen Sie mehr als nur Code. Sie übernehmen jede Lizenzentscheidung, jede Abhängigkeit und jede fehlende Hinweisdatei, die das vorherige Team ausgelassen hat. Wenn das Projekt als schneller Prototyp (oder von einem AI-Coding-Tool generiert) begann, wird Lizenzierung oft auf „später“ verschoben, bis jemand außerhalb des Teams unangenehme Fragen stellt.

Die Ausfallmodi sind normalerweise einfach — aber teuer:

• Eine Abhängigkeit steht unter einer Lizenz, die ein Kunde nicht akzeptiert.
• Erforderliche Lizenztexte oder Copyright-Hinweise sind nicht in dem enthalten, was Sie ausliefern.
• Der Build zieht transitive Pakete herein, die niemand überprüft hat.
• Ein kopierter Snippet, eine Schrift, ein Icon oder ein Asset hat Bedingungen, die nicht zu Ihrer beabsichtigten Nutzung passen.

Kunden und Partner verlangen Nachweise, weil sie sich schützen. Wenn sie Ihre Software ausliefern, Ihr SDK einbetten oder Ihr Produkt weiterverkaufen, können auch sie für Compliance verantwortlich werden. Enterprise-Beschaffungsteams fordern häufig ein Software Bill of Materials (SBOM), eine Third-Party-Notices-Datei und eine klare Aussage, wie Sie Lizenzpflichten erfüllen. Wenn Sie das nicht vorlegen können, verzögern sich Deals, Prüfungen werden strenger und Rechtsabteilungen können Rollouts blockieren.

Ein häufiger Irrtum ist, Repo-Eigentum als Lizenzrechte zu betrachten. Die Kontrolle über die GitHub-Organisation (oder dass Ihnen ein Auftragnehmer den Code übergibt) gewährt nicht automatisch die Erlaubnis, alles darin zu nutzen, zu verändern oder zu verbreiten. Open-Source-Lizenzen sind Genehmigungen mit Bedingungen. Sie sollten wissen, welche Bedingungen gelten, bevor Sie etwas ausliefern — vor allem, wenn Sie Binärdateien verteilen, ein kostenpflichtiges SaaS verkaufen oder Partnern Kopien geben.

Das praktische Ziel eines Audits ist klar: herausfinden, was tatsächlich enthalten ist, Lücken früh erkennen und klare Compliance-Artefakte erstellen. Es ersetzt keine Rechtsberatung und löst nicht jeden Einzelfall, aber es bringt Probleme ans Licht, solange sie noch günstig zu beheben sind.

Kurz: Lizenz-Grundlagen (ohne juristisches Kauderwelsch)

Eine Lizenz ist das Regelwerk dafür, wie Sie fremden Code nutzen können. Wenn Sie ein Repo übernehmen, übernehmen Sie auch seine Regeln und die dazugehörige Dokumentation. Ein nützlicher erster Schritt ist, „gering problematische Lizenzen“ von „Share-Alike-Lizenzen“ zu trennen und dann zu prüfen, ob Sie die grundlegenden Verpflichtungen erfüllen.

Permissive Lizenzen (wie MIT und Apache-2.0) erlauben in der Regel die Nutzung in fast jedem Produkt, auch kommerziellen. Der Aufwand ist administrativ: Copyright-Hinweise behalten, den Lizenztext beifügen, wo erforderlich, und nicht behaupten, Sie hätten das Originalwerk geschrieben.

Copyleft-Lizenzen (wie GPL) erlauben ebenfalls Nutzung, können aber verlangen, dass Sie beim Verteilen eines Produkts, das den Code enthält, den Quellcode des kombinierten Werks unter denselben Bedingungen freigeben. AGPL ist ähnlich, kann aber das „Source-Sharing“-Auslöseereignis auf Software ausweiten, die über ein Netzwerk angeboten wird — deshalb vermeiden SaaS-Teams sie oft.

In der Praxis bedeutet „Lizenzpflichten“ oft unglamouröse Arbeit:

• Erforderliche Lizenztexte und Copyright-Hinweise mit Ihrer Distribution beilegen
• Attribution in einer THIRD-PARTY-NOTICES (oder ähnlichen) Datei angeben
• Änderungen nachverfolgen, wenn die Lizenz das erwartet
• Bei Copyleft: bereit sein, Quellcode zu teilen, wenn nötig
• Marken oder Namen nicht in erlaubniswidriger Weise verwenden

Duale Lizenzierung überrascht Teams, weil dasselbe Projekt unter zwei unterschiedlichen Regeln angeboten werden kann. Eine Bibliothek kann „GPL für Open-Source-Projekte“ und „kommerzielle Lizenz für Closed-Source-Produkte“ sein, oder Dateien im Projekt können unterschiedliche Lizenzen haben. Wenn jemand Code aus der falschen Quelle gezogen hat, können strengere Bedingungen entstehen als erwartet.

Sie müssen nicht jedes Detail auswendig kennen. Sie müssen wissen, welche Lizenzen einfach einzuhalten sind, welche Ihre Vertriebsaufgaben ändern und welche einen Deal blockieren können, wenn das Compliance-Team des Kunden sie entdeckt.

Wo Lizenzen sich in einem modernen Repo verstecken

Die meisten Lizenzprobleme in vererbtem Code stecken nicht in der einen Abhängigkeit, an die Sie sich erinnern. Sie tauchen an Stellen auf, die niemand überprüft, bis ein Kunde Nachweise verlangt.

Beginnen Sie mit direkten Abhängigkeiten (Pakete in Dateien wie package.json, requirements.txt, go.mod, Gemfile). Die größere Überraschung sind transitive Abhängigkeiten: Pakete, die Ihre Pakete mitbringen. Eine direkte Bibliothek kann Dutzende transitive Lizenzen hereinziehen, und die können sich nach einem kleinen Versionswechsel ändern.

Frontend-Repos bringen eine weitere Versteckmöglichkeit: gebündelte Assets. Build-Tools packen Code oft in eine einzelne minifizierte Datei und dabei können Header oder Hinweise verloren gehen, die normalerweise mit dem Quellcode mitreisen. Kopierte Snippets sind ähnlich. Eine Helferfunktion, aus einem Blogpost, einem Gist oder einer Stack Overflow-Antwort eingefügt, kann trotzdem Lizenzbedingungen tragen.

Prüfen Sie auch, was rund um Ihre App ausgeliefert wird, nicht nur die App selbst. Container und Basisimages können OS-Pakete (und deren Lizenzen) enthalten, die in Produktion landen. Wenn Sie ein Dockerfile geerbt haben, erben Sie auch dessen Lizenzballast.

Häufige Verstecke:

• Abhängigkeits-Manifeste und Lockfiles (direkt und transitiv)
• Vendor-Ordner, kopierte Bibliotheken und „utils“-Verzeichnisse
• Gebündelte Frontend-Bundles und eingebettete Schriften/Icons
• Container-Basisimages und installierte OS-Pakete
• „Mystery-Code“, schnell hinzugefügter Code, einschließlich AI-generiertem Code, der lizenzierten Quellen ähnelt

Rote Flaggen, die Sie in 10 Minuten sehen können

Sie brauchen kein vollständiges Audit, um wahrscheinliche Probleme zu erkennen. Ein schneller Durchgang zeigt, ob ein Repo bei einer Kunden- oder Partnerprüfung möglicherweise scheitert.

Sehen Sie sich zuerst Abhängigkeits-Manifeste und Lockfiles an. Hunderte von Abhängigkeiten ohne Lockfile (oder mehrere Lockfiles, die nicht übereinstimmen) sind ein Signal, dass Sie nicht nachweisen können, was ausgeliefert wurde. Achten Sie auf private Registries oder Git-basierte Abhängigkeiten, die direkt aus Repos gezogen werden — diese fehlen oft an klaren Lizenzmetadaten.

Als Nächstes prüfen Sie, ob Build-Artefakte ins Repo committet wurden. Ordner wie dist, build, vendor, third_party oder kopierte minifizierte Bundles sind häufige Quellen für fehlende Hinweise. Wenn Code kopiert statt über einen Paketmanager installiert wurde, haben Sie eventuell keinen automatischen Weg, Lizenztexte zu sammeln.

Ist das Repo ein Monorepo (zum Beispiel packages/* oder libs/*), öffnen Sie ein paar interne Pakete. Fehlende LICENSE-Dateien oder unklare Ownership-Hinweise können chaotisch werden, wenn Pakete separat veröffentlicht werden.

Prüfen Sie schließlich, was tatsächlich geliefert wird. Fehlt eine Third-Party-Notices-Datei (oft THIRD_PARTY_NOTICES oder NOTICE) in Releases, Installern oder Container-Images, ist das eine gängige Compliance-Lücke.

Eine schnelle Triage:

• Lockfiles fehlen oder stimmen nicht mit dem Build überein
• Git-basierte oder „Unbekannte Lizenz“-Abhängigkeiten
• Committer Vendor- oder gebündelter Drittanbieter-Code
• Keine Notices-Datei im Release-Prozess

Wenn mehr als eines davon zutrifft, planen Sie eine tiefere Prüfung, bevor es jemand anderes findet.

Schritt-für-Schritt: Führen Sie ein Open-Source-Lizenz-Audit durch

Lizenz-Audits laufen reibungsloser, wenn Sie sie zuerst als Inventar behandeln und danach als Papierkram. Beginnen Sie damit, zu identifizieren, was Sie tatsächlich ausliefern, denn Verpflichtungen hängen oft von der Distribution ab.

1) Erstellen Sie ein sauberes Inventar des Ausgelieferten

Listen Sie jedes Auslieferungsartefakt auf, das Ihre Kontrolle verlässt: ein Web-Bundle, eine mobile App, ein Desktop-Installer, ein Container-Image, ein On-Prem-Paket oder sogar ein ZIP, das Sie an einen Partner senden.

Sammeln Sie dann die Dateien, die Ihren Abhängigkeitsgraph definieren. Versionen sind wichtig.

• Build-Manifeste wie package.json, pyproject.toml, requirements.txt, Gemfile, go.mod
• Lockfiles wie package-lock.json, yarn.lock, pnpm-lock.yaml, poetry.lock, Gemfile.lock, go.sum, Cargo.lock, composer.lock
• Container- und Deployment-Dateien (Dockerfiles, Helm-Charts, Build-Pipelines)
• Vendor-Ordner oder kopierter Code (vendor/, third_party/, manchmal libs/)
• App-Store-Metadaten oder „About“-Screens (häufige Stellen, um Hinweise anzuzeigen)

2) Scannen, bestätigen und Pflichten dokumentieren

Ein praktikabler Workflow, dem die meisten Teams folgen können:

1. Erzeugen Sie eine Abhängigkeitsliste (direkt und transitiv) aus Lockfiles und Build-Ausgaben.
2. Identifizieren Sie die Lizenz jeder Abhängigkeit in der jeweiligen Version. Markieren Sie alles als „unbekannt“ oder „kundenspezifisch“, das nicht klar ist.
3. Prüfen Sie Lizenzdaten über Quellen hinweg (Registry-Metadaten, LICENSE im Repo, Dateikopfzeilen).
4. Dokumentieren Sie die Pflichten, die Sie erfüllen müssen (Attribution, Beifügung des Lizenztexts, Platzierung der Hinweise, Auslöser für Source-Sharing).
5. Entscheiden Sie, was für Ihre Auslieferungsart akzeptabel ist (nur SaaS vs. Versand von Binärdateien oder On-Prem-Paketen).

Eine Desktop-App benötigt in der Regel Third-Party-Notices, die mit dem Installer gebündelt sind. SaaS-only kann anders sein, aber Kunden und Partner erwarten trotzdem saubere Unterlagen.

Vererbte Repos kommen oft ohne Lockfiles und mit kopiertem Code. Wenn Sie den Abhängigkeits-Satz nicht reproduzieren können, beheben Sie das zuerst. Ansonsten ist jede Lizenzentscheidung unsicher.

Häufige Fehler, die Compliance-Probleme auslösen

Die meisten Compliance-Probleme entstehen nicht aus böser Absicht. Sie passieren, weil Teams ein Repo übernehmen, schnell ausliefern und nie verifizieren, was drin ist.

Wiederkehrende Probleme:

• Metadaten passen nicht zur Realität. Ein README behauptet „MIT“, aber Paketmetadaten sind falsch oder es fehlt eine SPDX-Kennung.
• Kopierte Snippets ohne Attribution. „Nur eine Helferfunktion“ kann dennoch Lizenzbedingungen tragen.
• Starkes Copyleft an der falschen Stelle. GPL/AGPL-Abhängigkeiten können Pflichten erzeugen, die zu Ihrem Vertriebs- oder Hosting-Modell nicht passen.
• Nicht-Code-Assets werden ignoriert. Schriften, Icons, Bilder und UI-Kits haben oft eigene Lizenzen.
• Man verlässt sich auf Hörensagen. Ein Blogpost oder Kommentar ist keine Lizenz. Der Lizenztext und die Metadaten der Abhängigkeit sind entscheidend.

Selbst wenn Ihre direkte Abhängigkeit permissiv ist, kann eine transitive Abhängigkeit Probleme bringen. Nur Top-Level-Packages zu prüfen, verpasst die Probleme, die Kunden üblicherweise finden.

Ein typisches Szenario: Sie übernehmen einen Prototyp, sehen eine einzelne LICENSE-Datei und gehen davon aus, dass das Repo insgesamt abgedeckt ist. Später verlangt ein Enterprise-Kunde Third-Party-Notices und Sie entdecken gebündelte Assets mit eigenen Bedingungen und keinerlei Attribution.

Wie man Befunde behebt: Hinweise, Ersetzungen und Dokumentation

Nach einem Audit geht es nicht um Perfektion. Es geht um Klarheit: Was verwenden Sie, was müssen Sie mitliefern und was dürfen Sie nicht tun.

Beginnen Sie mit dem Erstellen (oder Aktualisieren) einer THIRD-PARTY-NOTICES-Datei. Halten Sie sie langweilig und vollständig. Für jede Abhängigkeit: Name, Version, Lizenz und wo sie erscheint (Web-App, Server, Mobile, Container-Image). Das ist oft das Erste, wonach Partner suchen.

Fügen Sie dann erforderliche Lizenztexte hinzu. Wenn eine Lizenz verlangt, dass der Text oder Copyright-Hinweise mit der Distribution enthalten sind, sammeln Sie diese Texte in einem licenses/-Ordner und verweisen Sie in THIRD-PARTY-NOTICES darauf.

Wenn Sie eine geschäftsmodellkritische riskante Lizenz finden (zum Beispiel starkes Copyleft in einer Bibliothek, die in ein Closed-Source-Produkt gelinkt wird), haben Sie in der Regel drei Wege: ersetzen, hinter einer Service-Grenze isolieren oder eine kommerzielle Lizenz erwerben. Die richtige Wahl hängt davon ab, wie die Komponente genutzt wird — nicht nur vom Lizenzlabel.

Machen Sie das Verfahren wiederholbar, indem Sie eine kurze COMPLIANCE.md hinzufügen, die erklärt, wie Sie das Inventar erzeugen und wo die Unterlagen liegen. Bleiben Sie praktisch: welche Lockfiles in Scope sind, was Sie ausschließen (dev-only Tools, Test-Frameworks) und warum, und welche Befehle den Scan reproduzieren.

Zuletzt setzen Sie eine leichte Intake-Regel für neue Abhängigkeiten: Mergen Sie kein neues Paket, bis dessen Lizenz bekannt ist (mit einer echten SPDX-Kennung, wenn möglich) und Hinweis-Updates bei Bedarf geregelt sind.

Was Partner normalerweise in einem Compliance-Paket sehen wollen

Die meisten Partner verlangen keinen juristischen Aufsatz. Sie wollen den Beweis, dass Sie wissen, welche Drittsoftware in Ihrem Produkt steckt, welche Regeln gelten und wer die Aktualität pflegt.

Ein gutes Paket beginnt meist mit einer kurzen Zusammenfassung: welche Lizenzfamilien in dem, was Sie ausliefern, vorkommen (permissiv wie MIT/Apache, schwaches Copyleft wie LGPL, starkes Copyleft wie GPL/AGPL), plus Scope des Scans und Datum.

Dann kommt die Evidenz: ein Abhängigkeitsinventar, das jemand anderes verifizieren kann — mit Namen, exakten Versionen, erkannten Lizenzen und wo jedes Element gefunden wurde (Lockfile, Vendor-Verzeichnis, Container-Layer, Build-Output).

Sie werden fast immer tatsächliche Texte und Attributionen brauchen, nicht nur Labels.

Praktisches Minimum zum Beifügen

• Eine kurze Lizenzzusammenfassung für das ausgelieferte Produkt
• Eine Abhängigkeitsliste mit Namen, Versionen und Lizenzen
• Third-Party-Notices (erforderliche Attribution und vollständige Lizenztexte, wo verlangt)
• Hinweise zu Ausnahmen (kommerziellen Lizenzen, schriftlichen Genehmigungen)
• Ein benannter Verantwortlicher und ein einfacher Review-Rhythmus

Ein Detail, das Rückfragen reduziert: weisen Sie Grauzonen vorab aus. Beispiele: „Paket X hatte keine Lizenzdatei, daher haben wir es ersetzt“ oder „Ein GPL-Dev-Tool wurde aus dem Produktionsimage entfernt und ist im SBOM ausgeschlossen."

Beispiel: vererbter Prototyp, Enterprise-Kundenprüfung

Ein Startup kauft einen funktionierenden Prototyp von einem Auftragnehmer und bringt ihn schnell in Produktion. Demos laufen gut, also konzentriert sich das Team auf Features und Vertrieb. Drei Monate später startet ein Enterprise-Kunde eine Sicherheits- und Beschaffungsprüfung und fragt: „Können Sie eine Liste aller Drittsoftware und Lizenzen bereitstellen?“

Das Team führt ein Audit durch und findet eine Copyleft-Abhängigkeit (GPL/AGPL) im Kernworkflow. Sie hat anfangs Zeit gespart, aber die Bedingungen passen nicht zu dem Vertriebs- und Distributionsplan des Startups.

Sie pausieren den Deal und tun parallel drei Dinge: die genaue Abhängigkeit/Version und deren Verwendung im Produkt bestätigen, sie durch eine permissive Alternative ersetzen und die Integration refaktorisieren sowie die Unterlagen so bereinigen, dass der Kunde eine vollständige, konsistente Darstellung sieht.

Was sie zurücksenden, ist kurz und konkret:

• Eine Abhängigkeitsliste mit Namen, Versionen und Lizenzen
• Eine Third-Party-Notices-Datei, die dem Ausgelieferten entspricht
• Eine Notiz, die die entfernte Abhängigkeit und die Ersetzung dokumentiert
• Ein Protokoll von Scan-Datum und Tool-Einstellungen

Nach Abschluss des Deals fügen sie eine Lizenzprüfung in CI hinzu, verlangen Hinweis-Updates vor Releases und führen eine Liste „erlaubter Lizenzen“, die zu ihrem Geschäftsmodell passt.

Schnelle Checkliste und nächste Schritte

Behandeln Sie Lizenzarbeit wie eine Release-Anforderung, nicht als einmaligen Sprint. Bevor Kundengespräche ernst werden, sollten Sie die Frage beantworten können: „Was liefern wir genau aus und unter welchen Lizenzen?“

Eine Vor-Release-Basislinie:

• Komplettes Inventar dessen, was Sie ausliefern (inklusive transitiver Abhängigkeiten und gebündelter Assets)
• Gepinnte Versionen und bekannte Lizenzen (kein „unknown“, „custom“ oder „siehe README“ offen lassen)
• Hinweise bereit zum Mitliefern (Third-Party-Notices, erforderliche Copyright-Angaben, erforderliche Lizenztexte)
• Reproduzierbare Builds (commitete und tatsächlich genutzte Lockfiles)
• Ein klar benannter Verantwortlicher für laufende Updates

Wenn Sie in den nächsten 1–2 Wochen ein Release haben, priorisieren Sie Notices und reproduzierbare Builds. Das ist das, was Partner schnell verifizieren können. Haben Sie mehr Zeit, fügen Sie eine Dependency-Intake-Regel hinzu, damit Lizenzthemen nicht erst während der Beschaffung auftauchen.

Ist das Repo vererbt oder AI-generiert, erwarten Sie Lücken: fehlende Lockfiles, ungenutzte Pakete, kopierter Code ohne Header und Build-Artefakte, die Drittdateien bündeln. Ist die Codebasis bereits instabil, ist es oft schneller, zuerst den Build und das Inventar zu reparieren und dann den Papierkram zu erledigen.

Hilfe holen, wenn das Repo unordentlich oder AI-generiert ist

Bei einem vererbten, halb funktionalen Repo fühlt sich Lizenzarbeit oft wie raten an. Es wird komplizierter, wenn Code schnell von AI-Tools erzeugt wurde, weil Abhängigkeiten ohne Review hinzugefügt werden können, Snippets keine Header haben und ausgelieferte Artefakte Drittdateien enthalten, an die sich niemand erinnert.

Hilfreich ist die Arbeit in zwei Schienen aufzuteilen:

• Rechtsentscheidungen: Auslegung von Pflichten (zum Beispiel, ob Ihre Distribution Copyleft-Bedingungen auslöst oder wie mit vergangenen Releases ohne Hinweise umzugehen ist).
• Engineering-Aufräumarbeiten: Inventar, Automatisierung und Repo-Bereinigung, damit Sie den Prozess bei jedem Release wiederholen können.

Praktisch ist oft: Ingenieure liefern die Fakten (Abhängigkeitsliste, Lizenzen, Notices), und die Rechtsabteilung prüft Randfälle und genehmigt Formulierungen.

Wenn Sie praktische Hilfe brauchen, um einen kaputten, vererbten Prototyp in etwas zu verwandeln, das Sie ausliefern und in Prüfungen verteidigen können, hilft FixMyMess (fixmymess.ai) bei der Diagnose und Reparatur von AI-generierten oder vererbten Codebasen, inklusive Refactoring, Security-Härtung und Deployment-Vorbereitung. Ein sauberer, stabiler Build ist oft der schnellste Weg zu einem vertrauenswürdigen Abhängigkeitsinventar und einem Notices-Paket, das Partner akzeptieren.

Bevor Sie Hilfe anfordern, sammeln Sie ein paar Basics, damit die Arbeit präzise bleibt: Repo-Zugriff (oder ein bereinigter Export), Ihre aktuellen Build- und Release-Schritte, ein Beispiel-Auslieferungsartefakt (Image/Zip/Installer/Bundle) und alle Kundenfragebögen, die Sie bereits erhalten haben.