IT- / Datenschutzrecht
Software-Lizenzvertrag OSS-Kompatibilität
anymize entfernt Mandanten- und Vendor-Klarnamen, interne Produkt- und Modul-Bezeichnungen sowie Komponentenlisten automatisch aus dem Lizenzvertrag und der SBOM, bevor sie an GPT, Claude oder Gemini gehen — und setzt sie nach der KI-Antwort wieder ein. So strukturieren Sie die OSS-Kompatibilitäts-Prüfung mit Copyleft-Verkettung, MIT/Apache/BSD-Pflichten und SBOM-Auswertung (CycloneDX/SPDX) in Minuten, ohne § 43a BRAO oder § 203 StGB zu berühren.
Schwierigkeit: Spezialist · Datenklasse: Mandantendaten · Letztes Review:
Zur Orientierung gedacht. Die anwaltliche Würdigung im Einzelfall bleibt selbstverständlich bei Ihnen — KI-Outputs sind vor jeder Verwendung zu prüfen. Mehr dazu am Ende.
Anwendungsbereich
Worum geht es hier?
Software-Lizenzverträge sind heute fast nie reine proprietäre Lizenzen. Selbst klassische „Enterprise-Software“ trägt im Inneren Dutzende bis Hunderte Open-Source-Komponenten — und damit deren Lizenz-Pflichten. Wer einen Lizenzvertrag manuell auf OSS-Kompatibilität prüft, sitzt 90–180 Minuten an Vertragstext, SBOM und Lizenz-Katalogen. Die Pflicht zur Software Bill of Materials hat durch den Cyber Resilience Act (Verordnung EU 2024/2847, in Kraft 11.12.2024) und durch sektorale Vorgaben (BSI-TR, FDA-Pre-Market, US-Executive-Order 14028) zusätzlichen Schub bekommen. Mit anymize geht der Vertragstext und die SBOM anonymisiert an ein Frontier-Modell — Mandantenname, Vendor-Identität, interne Produkt- und Modul-Bezeichnungen verlassen das Haus nicht. Die anwaltliche Würdigung — Verteilungs-Begriff, Copyleft-Verkettungs-Tiefe, Konzern-Compliance, Indemnification-Strategie — bleibt anwaltliche Eigenleistung.
Für wen passt das?
Zielgruppe und Kontext
- Rolle
- Fachanwält:in für IT-Recht; Fachanwält:in für gewerblichen Rechtsschutz mit IT-Schwerpunkt; Inhouse-Counsel bei Software-Hersteller-Mandantschaft; Open-Source-Compliance-Beauftragte:r in der Kanzlei; Wirtschaftsanwält:in im M&A-Kontext mit Code-Audit-Mandat.
- Seniorität
- Berufserfahrung mittel bis Spezialist:in — Lizenz-Reviews sind technisch dicht, brauchen ein Verständnis von Verteilungs-Begriff, Linking-Architektur (statisch/dynamisch), SaaS-Bereitstellung und Konzern-Compliance. Bei M&A-Code-Audits und bei Konzernen mit zentralem OSS-Compliance-Programm den geübten Blick.
- Kanzleigröße
- Einzelkanzlei mit IT-/IP-Fokus bis Großkanzlei mit Software-Beratungspraxis. Der Effizienz-Hebel rechnet sich besonders bei SBOM-getriebenen Code-Audits (M&A, Due Diligence, Cyber-Resilience-Audits) und bei Mandantschaft mit hoher Vertragsfrequenz im Software-Sourcing.
- Spezifische Kontexte
- Mandantschaft erwirbt oder lizenziert Standard-Software mit OSS-Anteilen und braucht eine Compliance-Bewertung; M&A mit Code-Audit-Auftrag; SBOM-Pflicht aus Cyber Resilience Act, BSI-TR oder sektoraler Regulierung; Hersteller-Mandantschaft konfiguriert die eigene Lizenz-Strategie (Single-License vs. Dual-License); Inhouse-Entwicklung mit eingebetteten OSS-Komponenten und Distribution an Endkunden.
Die Situation in der Kanzlei
So bringen Sie Tempo und Sorgfalt zusammen
OSS-Lizenz-Prüfung ist eines der drei klassischen Software-Beratungsthemen — und gleichzeitig eines der unterschätzten. Der Lizenzvertrag des Vendors regelt die proprietäre Komponente; die OSS-Anteile bringen ihre eigenen Pflichten mit, die der Vendor weder erkennt noch durchreicht. Wer einen Lizenzvertrag mit beigefügter SBOM manuell prüft, sitzt 90–180 Minuten am Vergleich: Welche Komponenten sind Copyleft (GPL v2/v3, AGPL, LGPL)? Welche permissive (MIT, Apache 2.0, BSD)? Welche kommen mit Patentklauseln, welche mit Werbe-Pflichten, welche mit Quellcode-Bereitstellungs-Pflichten bei Verteilung? Wer ChatGPT oder Claude direkt nutzen würde, käme in Minuten zur Lizenz-Matrix — verletzt aber § 43a BRAO und § 203 StGB, sobald Mandantenname, Vendor-Identität und interne Produkt- und Modul-Bezeichnungen das Haus verlassen. SBOMs enthalten zusätzlich oft interne Repository-Pfade, Build-Identifier und Entwickler-Namen, die das Geschäftsgeheimnis der Mandantschaft betreffen. anymize löst genau diesen Konflikt: Klarnamen werden vor dem KI-Aufruf zu Platzhaltern; die KI-Antwort kommt strukturiert zurück, anymize re-identifiziert. Die Vertraulichkeit ist strukturell gewahrt.
Was Sie davon haben
Zeit, Wert, Vertraulichkeit
Zeit pro Lizenz-Review
~90 Min
Frontier-KI strukturiert Lizenz-Matrix mit Copyleft-Verkettung, Pflicht-Katalog je Komponente und Distribution-Bewertung in unter 15 Minuten. Anwaltliche Würdigung des Verteilungs-Begriffs, Konzern-Compliance-Strategie und Indemnification kommen wie gewohnt obendrauf.
Mehrwert pro Vertrag
€ 375–675
Stundensatz IT-/IP-Recht (€ 250–450/h) angewandt auf 90 Minuten freigespielte Strukturierungs-Zeit.
Vertraulichkeit
strukturell
anymize entfernt 40+ Kategorien personenbezogener und geschäftsgeheimnis-relevanter Daten — Mandantenname, Vendor-Identität, Produkt- und Modul-Bezeichnungen, Repository-Pfade, Entwickler-Namen, Build-Identifier — bevor SBOM und Vertrag das Haus verlassen.
Erkennungsrate
>95 %
Dreifach geprüft (Algorithmus + zwei spezialisierte KI-Prüfungen). Restmenge kontrollieren Sie im Vorschau-Modus vor dem KI-Aufruf.
So gehen Sie vor
In 5 Schritten zum Antrag
Lizenzvertrag und SBOM bereitstellen. Sie übernehmen den Software-Lizenzvertrag des Vendors (PDF, Word, Markdown), die zugehörige SBOM (idealerweise CycloneDX oder SPDX, alternativ Excel-Komponentenliste) und ggf. das Kanzlei-Playbook für Lizenz-Reviews in den anymize-Arbeitsplatz. Klären Sie: Bereitstellungs-Form (On-Premise mit Verteilung, SaaS ohne Verteilung, eingebettet in eigenes Produkt)? Distribution an Dritte? Linking-Architektur (statisch/dynamisch, Plugin, IPC)? Konzern-Setup mit interner Weitergabe?
Sie
Mandatsgrundlage · Verteilungs-Anwendungsbereich
anymize anonymisiert automatisch. Über 40 Kategorien personenbezogener und geschäftsgeheimnis-relevanter Daten — Mandantenname, Vendor-Identität, Produkt- und Modul-Bezeichnungen, interne Repository-Pfade, Entwickler-Namen, Build-Identifier, Sub-Lizenznehmer — werden durch semantische Platzhalter ersetzt. Sie sehen die Vorschau vor dem KI-Aufruf. Bei großen SBOMs mit hunderten Komponenten empfehlen wir, die Vorschau in Stichproben zu sichten.
anymize
§ 43a BRAO Verschwiegenheit · § 203 StGB · Geschäftsgeheimnis
Frontier-KI strukturiert. Der pseudonymisierte Lizenzvertrag mit SBOM geht an Ihr gewähltes Modell — GPT, Claude oder Gemini, alle in anymize verfügbar. Mit dem unten stehenden Prompt fragen Sie eine OSS-Lizenz-Matrix mit den fünf Kern-Dimensionen ab: Lizenz-Klassifikation (Copyleft-Stärke), Pflicht-Katalog je Lizenz, Verteilungs-Bewertung, Kompatibilitäts-Konflikte und SBOM-Vollständigkeit. Die KI sieht keine Klarnamen — sie arbeitet ausschließlich mit den Platzhaltern.
GPT / Claude / Gemini in anymize
Lizenz-Matrix in Minuten
anymize re-identifiziert. Die KI-Antwort kommt mit Platzhaltern zurück; anymize setzt automatisch die Originaldaten wieder ein. Sie erhalten eine Lizenz-Matrix, die Sie anwaltlich würdigen: Verteilungs-Begriff im konkreten Mandats-Setup, Copyleft-Verkettungs-Tiefe (statisch/dynamisch/SaaS-AGPL-Frage), Konzern-Compliance, Patentklausel-Effekte, Indemnification-Strategie gegen den Vendor.
anymize + Sie
Bidirektionale Anonymisierung · anwaltliche Würdigung
Mandanten-Empfehlung und Verhandlung. Sie schicken die Lizenz-Matrix mit Mandanten-Empfehlung an die Mandantschaft. Bei Compliance-Lücken: Empfehlung zur Lizenz-Bereinigung (Komponenten-Tausch, Lizenz-Klärung mit Vendor, OSS-Pflicht-Erfüllung), zur Indemnification-Klausel-Verhandlung oder zur Distribution-Architektur-Anpassung. Bei M&A-Mandaten: Code-Audit-Bericht für die Due-Diligence-Dokumentation.
Sie
Anwaltliche Beratung im Mandatsverhältnis
Womit Sie arbeiten
So setzen Sie anymize konkret ein
Was anymize tut
- Erkennt 40+ Kategorien personenbezogener und geschäftsgeheimnis-relevanter Daten — Mandantenname, Vendor-Identität, Produkt- und Modul-Bezeichnungen, interne Repository-Pfade, Entwickler-Namen, Build-Identifier — mit über 95 % Erkennungsrate.
- Dreistufige Prüfung: Algorithmische Analyse, dann zwei spezialisierte KI-Prüfungen, die auch Kontext berücksichtigen (z. B. Komponenten-Name vs. Lizenz-Bezeichnung).
- Bidirektionale Anonymisierung: Platzhalter werden eingesetzt, das Frontier-Modell antwortet mit Kontext, anymize re-identifiziert beim Empfang.
- Daten in deutschen Rechenzentren (Hetzner). Originaldokumente werden nicht gespeichert — nur die Zuordnung Platzhalter ↔ Klarname, mit Aufbewahrungsfrist nach Ihrer Wahl von 24 Stunden bis unbegrenzt.
Was Sie als Anwält:in tun
- Bereitstellungs-Form, Distribution und Linking-Architektur klären — der Verteilungs-Begriff ist die Schlüssel-Frage des OSS-Rechts.
- Vorschau der Anonymisierung sichten — bei großen SBOMs in Stichproben prüfen, ob Komponenten-Namen versus Lizenz-Namen sauber unterschieden sind.
- Lizenz-Matrix anwaltlich würdigen — die Copyleft-Verkettungs-Tiefe und der Verteilungs-Begriff im konkreten Setup leistet die KI bewusst nicht abschließend.
- Konzern-Compliance prüfen — interne Weitergabe innerhalb eines Konzerns ist nach GPL-Auslegung umstritten; pragmatisch ist die Klärung über Konzern-Vertrag.
- Mandanten-Empfehlung formulieren, Verhandlungs-Strategie für Indemnification abstimmen, ggf. Lizenz-Bereinigung empfehlen.
Daten-Input
Software-Lizenzvertrag des Vendors (PDF, Word, Markdown), SBOM (CycloneDX, SPDX, Excel-Komponentenliste), ggf. Architektur-Diagramm zur Linking-Form, optional Kanzlei-Playbook für Lizenz-Reviews und Konzern-Compliance-Vorgabe der Mandantschaft.
Output-Kontrolle
Pseudonymisierter Text geht an die KI. Re-identifizierte Lizenz-Matrix kommt zurück. anymize selbst trifft keine inhaltlichen Aussagen — die Strukturierung leistet das Frontier-Modell, die Würdigung machen Sie.
Freigabeprozess
Sie behalten jederzeit die Hoheit: Sichtung der Anonymisierung, anwaltliche Bewertung der Verteilungs-Frage, Mandanten-Beratung, Verhandlungs-Strategie — alles im üblichen Kanzlei-Workflow. anymize ist der Anonymisierungs-Layer, keine Workflow-Software.
Die KI-Anweisung
Prompt zum Kopieren
So nutzen Sie diesen Prompt:
1. Lizenzvertrag und SBOM in anymize einfügen — die Anonymisierung läuft automatisch (Mandantenname, Vendor-Identität, Produkt- und Modul-Bezeichnungen, Repository-Pfade, Entwickler-Namen werden zu Platzhaltern).
2. Diesen Prompt kopieren und an den Vertrag anhängen, die SBOM als zweiten Block daruntersetzen.
3. In anymize unter „Tools → Reasoning“ auf „Thinking-Modus“ stellen, dann KI-Aufruf starten — der Output kommt re-identifiziert zurück.
# Rolle
Du bist Lizenz-Analyse-Assistenz fuer eine IT-/IP-Rechts-Kanzlei.
Rechtsstand: <heutiges Datum — bitte aktuell ermitteln und hier einsetzen>.
# Aufgabe
Pruefe den vorgelegten Software-Lizenzvertrag mit beigefuegter SBOM
systematisch auf OSS-Kompatibilitaet gegen
(1) den Verteilungs-Begriff der jeweiligen Lizenz (GPL/LGPL/AGPL/
MIT/Apache 2.0/BSD/MPL/EPL),
(2) den Pflicht-Katalog je Lizenz (Quellcode-Bereitstellung,
Lizenz-Text-Mitlieferung, Patentklauseln, Werbe-Pflichten),
(3) Kompatibilitaets-Konflikte zwischen Komponenten,
(4) SBOM-Vollstaendigkeit und -Format (CycloneDX/SPDX) und
(5) die SBOM-Pflichten aus Cyber Resilience Act (VO 2024/2847,
ab 11.12.2024 in Kraft, mit gestaffelten Anwendungs-Daten).
Liefere eine Lizenz-Matrix mit Soll-Ist-Vergleich und einem
Compliance-Status je Komponente. Die anwaltliche Wertung des
Verteilungs-Begriffs im konkreten Mandats-Setup, die Copyleft-
Verkettungs-Tiefe und die Indemnification-Strategie sind NICHT
deine Aufgabe.
# Inhalt
## Abschnitt 1 — Lizenz-Klassifikation (Copyleft-Staerke)
Tabelle mit Spalten: Komponente | Version | Lizenz | Klasse | Verteilungs-Trigger
Klassen:
- [STRONG-COPYLEFT] — GPL v2/v3, AGPL v3 (AGPL auch bei SaaS)
- [WEAK-COPYLEFT] — LGPL v2.1/v3, MPL 2.0, EPL 2.0
- [PERMISSIVE] — MIT, Apache 2.0, BSD-2/3, ISC, zlib
- [PUBLIC-DOMAIN] — Unlicense, CC0, WTFPL
- [PROPRIETARY] — proprietaere Vendor-Lizenz oder Dual-License-Wahl
- [UNKLAR] — Lizenz nicht erkannt, deklariert "see LICENSE" ohne Verweis
## Abschnitt 2 — Pflicht-Katalog je Komponente
Tabelle mit Spalten: Komponente | Pflicht | Erfuellt? | Lueckenbeschreibung
Pflichten zu pruefen:
- Quellcode-Bereitstellung bei Verteilung (GPL v2/v3, LGPL, MPL Datei-basiert)
- Lizenz-Text und Copyright-Notice in Distribution (alle OSS)
- Aenderungs-Markierung im Quellcode (GPL v3, Apache 2.0 NOTICE)
- Patent-Lizenz-Klausel und Patent-Retaliation (Apache 2.0, GPL v3)
- AGPL-Network-Trigger (SaaS-Bereitstellung als Verteilung i. S. AGPL)
- LGPL-Linking-Pflicht (statisch/dynamisch unterscheiden)
- Werbe-Pflicht oder Attribution-Pflicht (4-Klausel-BSD historisch)
- Inkompatibilitaeten (GPL v2 only und Apache 2.0, GPL und MPL 1.x)
## Abschnitt 3 — Verteilungs-Bewertung im konkreten Setup
Tabelle mit Spalten: Bereitstellungs-Form | Verteilung i. S. der Lizenz? | Konsequenz
Bereitstellungs-Formen zu klassifizieren:
- On-Premise mit Distribution (klassische Verteilung — alle Pflichten greifen)
- SaaS ohne Distribution (GPL-Pflichten greifen meist nicht;
AGPL-Network-Trigger greift)
- Eingebettet in eigenes Produkt mit Auslieferung an Endkunden
- Konzern-interne Weitergabe (umstritten — Hinweis [ANWALT-PRUEFUNG])
- Plugin-Architektur (Plugin-Distribution kann eigene Lizenz tragen)
## Abschnitt 4 — Kompatibilitaets-Konflikte
Tabelle mit Spalten: Komponente A | Komponente B | Konflikt | Konsequenz
Bekannte Konflikt-Muster:
- GPL v2-only und Apache 2.0 (Patent-Klausel inkompatibel)
- GPL und MPL 1.x (vor MPL 2.0)
- AGPL und proprietaere Komponenten in derselben Network-
bereitgestellten Anwendung
- Lizenz-Faerbung durch Linking — Effekt der GPL auf das
Gesamtwerk
## Abschnitt 5 — SBOM-Vollstaendigkeit und CRA-Konformitaet
Tabelle mit Spalten: Anforderung | Soll | Ist | Luecke?
Anforderungen:
- Format: CycloneDX oder SPDX in maschinenlesbarer Form
- Komponenten-Identifikation: Name, Version, Hash, PURL
- Lizenz je Komponente
- Transitive Abhaengigkeiten (Tiefe vollstaendig)
- Hersteller-Identifikation je Komponente
- Aktualitaets-Stand der SBOM (CRA verlangt fortlaufende
Aktualisierung)
- Sicherheits-Schwachstellen-Verweise (CVE) — nicht zwingend
Lizenz-relevant, aber CRA-relevant
## Abschnitt 6 — Compliance-Status-Uebersicht
Tabelle mit Spalten: Komponente | Compliance-Status | Hinweis
Status-Stufen:
- [OK] — Lizenz erkannt, Pflichten erfuellt, kein Konflikt
- [PFLICHT-LUECKE] — Pflicht nicht erfuellt (z. B. Lizenz-Text
fehlt in Distribution)
- [KONFLIKT] — Kompatibilitaets-Konflikt mit anderer Komponente
- [STARK-COPYLEFT-WARNUNG] — GPL/AGPL in Architektur, die zur
Lizenz-Faerbung fuehren koennte
- [SBOM-LUECKE] — Komponente in SBOM unzureichend beschrieben
- [ANWALT-PRUEFUNG] — Verteilungs-Begriff im konkreten Setup
anwaltlich zu klaeren
# Format
Markdown. Tabellen fuer alle Abschnitte. Bei zitierten Lizenz-
Namen immer mit Version (z. B. "GPL v2-only", "GPL v3-or-later",
"Apache 2.0").
# Verbote
KEINE Empfehlung zur abschliessenden Verteilungs-Bewertung im
konkreten Setup — der Verteilungs-Begriff ist anwaltlich.
KEINE Aussage zur Lizenz-Faerbung als Rechtsfolge ohne Hinweis
auf Streitstand.
KEINE Aussage zur Konzern-Privileg-Frage ohne Hinweis auf
Streitstand.
KEINE Aussage zur Marktueblichkeit von Indemnification-Klauseln.
KEINE Bezugnahme auf KI-Modell-Versionen oder Hersteller-Marketing.So sieht der Sachverhalt aus
Pseudonymisierter Eingabetext
Vertragsparteien:
Lizenzgeber: [[Unternehmensname-8a3c]],
[[Adresse-8a3c]], vertreten durch [[Vorname-8a3c]] [[Nachname-8a3c]].
Lizenznehmer (Mandant): [[Unternehmensname-2f9b]],
[[Adresse-2f9b]], vertreten durch [[Vorname-2f9b]] [[Nachname-2f9b]].
Lizenzgegenstand:
Standard-Software [[Produktname-8a3c]] in der Version 14.2, mit
Modulen Reporting, Analytics und Integration in das ERP-System
[[Produktname-2f9b]] der Mandantschaft. Bereitstellung On-Premise
mit Installation in der Mandanten-Infrastruktur. Verteilung an
Tochtergesellschaften der Mandantschaft im Rahmen einer Konzern-
Lizenz vorgesehen.
Auszug § 4 (Lizenzgewaehrung):
Der Lizenzgeber gewaehrt dem Lizenznehmer ein nicht-ausschliessliches,
nicht uebertragbares Nutzungsrecht an der Standard-Software. Eine
Weitergabe an Dritte ist nicht gestattet; konzern-interne Nutzung
ist im Rahmen einer separaten Konzern-Klausel (Anlage 2) geregelt.
Auszug § 7 (Open-Source-Anteile):
Die Standard-Software enthaelt Open-Source-Komponenten. Eine
Software Bill of Materials ist als Anlage 4 beigefuegt. Der
Lizenzgeber gewaehrleistet, dass die Verwendung der Open-Source-
Komponenten den jeweiligen Lizenzbedingungen entspricht.
Eine Freistellung des Lizenznehmers fuer Verletzungen der
Open-Source-Lizenzen durch den Lizenzgeber wird nicht uebernommen.
Auszug § 12 (Haftung):
Die Haftung des Lizenzgebers ist auf den Betrag der fuer zwoelf
Monate vereinbarten Lizenzvergueung begrenzt. Diese Begrenzung
gilt nicht bei Vorsatz oder grober Fahrlaessigkeit.
Anlage 4 (SBOM-Auszug, CycloneDX 1.5):
- [[Modulname-8a3c-01]] v2.14.0 Lizenz: MIT
- [[Modulname-8a3c-02]] v1.0.7 Lizenz: Apache-2.0
- [[Modulname-8a3c-03]] v3.2.1 Lizenz: GPL-2.0-only
- [[Modulname-8a3c-04]] v1.4.0 Lizenz: LGPL-2.1-or-later
- [[Modulname-8a3c-05]] v0.9.3 Lizenz: AGPL-3.0-only
- [[Modulname-8a3c-06]] v5.1.2 Lizenz: BSD-3-Clause
- [[Modulname-8a3c-07]] v0.4.1 Lizenz: "see LICENSE file"
- [[Modulname-8a3c-08]] v2.0.0 Lizenz: MPL-2.0
- [[Modulname-8a3c-09]] v1.7.0 Lizenz: ISC
Anlage 2 (Konzern-Klausel, Auszug):
Lizenznehmer ist berechtigt, die Standard-Software an mit ihm
i. S. d. §§ 15 ff. AktG verbundene Unternehmen weiterzugeben,
sofern diese Unternehmen die Lizenzbedingungen anerkennen und
in dieselbe Konzern-Compliance-Vorgabe eingebunden sind.So liefert anymize zurück
Der Antrags-Entwurf
# Software-Lizenzvertrag — OSS-Kompatibilitaets-Matrix
## Abschnitt 1 — Lizenz-Klassifikation
| Komponente | Version | Lizenz | Klasse | Verteilungs-Trigger |
|---|---|---|---|---|
| [[Modulname-8a3c-01]] | v2.14.0 | MIT | [PERMISSIVE] | Verteilung mit Lizenz-Text |
| [[Modulname-8a3c-02]] | v1.0.7 | Apache-2.0 | [PERMISSIVE] | Verteilung mit Lizenz-Text + NOTICE + Patent-Klausel |
| [[Modulname-8a3c-03]] | v3.2.1 | GPL-2.0-only | [STRONG-COPYLEFT] | Verteilung loest Quellcode-Pflicht aus |
| [[Modulname-8a3c-04]] | v1.4.0 | LGPL-2.1-or-later | [WEAK-COPYLEFT] | Verteilung mit Linking-Pflicht (statisch/dynamisch) |
| [[Modulname-8a3c-05]] | v0.9.3 | AGPL-3.0-only | [STRONG-COPYLEFT] | Network-Trigger — auch SaaS-Bereitstellung loest aus |
| [[Modulname-8a3c-06]] | v5.1.2 | BSD-3-Clause | [PERMISSIVE] | Verteilung mit Lizenz-Text + Copyright-Notice |
| [[Modulname-8a3c-07]] | v0.4.1 | "see LICENSE file" | [UNKLAR] | Pflicht-Katalog nicht bestimmbar [SBOM-LUECKE] |
| [[Modulname-8a3c-08]] | v2.0.0 | MPL-2.0 | [WEAK-COPYLEFT] | Datei-basierte Copyleft-Pflicht |
| [[Modulname-8a3c-09]] | v1.7.0 | ISC | [PERMISSIVE] | Verteilung mit Lizenz-Text |
## Abschnitt 2 — Pflicht-Katalog je Komponente
| Komponente | Pflicht | Erfuellt? | Lueckenbeschreibung |
|---|---|---|---|
| [[Modulname-8a3c-01]] (MIT) | Lizenz-Text + Copyright in Distribution | unklar | im Vertrag nicht adressiert [STANDARD] |
| [[Modulname-8a3c-02]] (Apache-2.0) | Lizenz-Text + NOTICE in Distribution | unklar | NOTICE-Datei-Pflicht nicht erwaehnt [STANDARD] |
| [[Modulname-8a3c-02]] (Apache-2.0) | Patent-Lizenz-Klausel und Retaliation | informativ | Wirkt automatisch; Hinweis fuer Indemnification |
| [[Modulname-8a3c-03]] (GPL-2.0-only) | Quellcode-Bereitstellung bei Verteilung | unklar | bei On-Premise-Distribution Pflicht ausgeloest [KRITISCH] |
| [[Modulname-8a3c-03]] (GPL-2.0-only) | Lizenz-Faerbungs-Risiko bei statischem Linking | unklar | Linking-Architektur nicht beschrieben [ANWALT-PRUEFUNG] |
| [[Modulname-8a3c-04]] (LGPL-2.1+) | Linking-Pflicht (statisch: Quellcode-Pflicht; dynamisch: erleichtert) | unklar | Linking-Form nicht beschrieben [ANWALT-PRUEFUNG] |
| [[Modulname-8a3c-05]] (AGPL-3.0) | Network-Trigger bei SaaS-Bereitstellung | informativ | Setup ist On-Premise — Trigger greift hier nicht; bei zukuenftigem SaaS-Wechsel kritisch [STANDARD] |
| [[Modulname-8a3c-05]] (AGPL-3.0) | Quellcode-Bereitstellung bei Verteilung | unklar | bei On-Premise-Distribution Pflicht ausgeloest [KRITISCH] |
| [[Modulname-8a3c-06]] (BSD-3) | Lizenz-Text + Copyright + No-Endorsement-Klausel | unklar | im Vertrag nicht adressiert [STANDARD] |
| [[Modulname-8a3c-07]] ("see LICENSE") | Pflicht-Katalog nicht bestimmbar | nein | SBOM-Luecke — Lizenz-Klaerung notwendig [SBOM-LUECKE] |
| [[Modulname-8a3c-08]] (MPL-2.0) | Datei-basierte Copyleft-Pflicht | unklar | nur geaenderte MPL-Dateien quelloffen [STANDARD] |
| [[Modulname-8a3c-09]] (ISC) | Lizenz-Text + Copyright | unklar | im Vertrag nicht adressiert [STANDARD] |
## Abschnitt 3 — Verteilungs-Bewertung im konkreten Setup
| Bereitstellungs-Form | Verteilung i. S. der Lizenz? | Konsequenz |
|---|---|---|
| On-Premise mit Installation Mandanten-Infrastruktur | ja — klassische Verteilung | alle Verteilungs-Pflichten greifen [KRITISCH bei GPL/AGPL] |
| Konzern-interne Weitergabe an Tochtergesellschaften (Anlage 2) | umstritten — Konzern-Privileg streitig | [ANWALT-PRUEFUNG] — FSF und einzelne Gerichte uneins |
| Spaetere SaaS-Bereitstellung (hypothetisch) | nur AGPL-Network-Trigger | bei Wechsel zu SaaS waere AGPL-Pflicht der Quellcode-Bereitstellung gegenueber Network-Nutzern auszuloesen [PRUEFUNG] |
## Abschnitt 4 — Kompatibilitaets-Konflikte
| Komponente A | Komponente B | Konflikt | Konsequenz |
|---|---|---|---|
| [[Modulname-8a3c-03]] (GPL-2.0-only) | [[Modulname-8a3c-02]] (Apache-2.0) | Patent-Klausel inkompatibel mit GPL-2-only | bei statischem Linking ins selbe Werk [KONFLIKT] — Architektur klaeren [ANWALT-PRUEFUNG] |
| [[Modulname-8a3c-05]] (AGPL-3.0) | proprietaerer Vendor-Code | AGPL-Faerbung bei Network-Bereitstellung | bei zukuenftigem SaaS-Wechsel [STARK-COPYLEFT-WARNUNG] |
| [[Modulname-8a3c-03]] (GPL-2.0-only) | proprietaerer Vendor-Code | Faerbungs-Risiko bei statischem Linking | bei kombiniertem Werk [STARK-COPYLEFT-WARNUNG] |
## Abschnitt 5 — SBOM-Vollstaendigkeit und CRA-Konformitaet
| Anforderung | Soll | Ist | Luecke? |
|---|---|---|---|
| Format CycloneDX/SPDX maschinenlesbar | Pflicht | CycloneDX 1.5 | erfuellt |
| Komponenten-Identifikation Name + Version | Pflicht | erfuellt | — |
| Hash und PURL je Komponente | empfohlen | nicht ersichtlich | [STANDARD] |
| Lizenz je Komponente | Pflicht | weitgehend erfuellt | [[Modulname-8a3c-07]] mit "see LICENSE" [SBOM-LUECKE] |
| Transitive Abhaengigkeiten | Pflicht | nicht ersichtlich, ob Tiefe vollstaendig | [PRUEFUNG] |
| Hersteller je Komponente | empfohlen | nicht ersichtlich | [STANDARD] |
| Aktualitaets-Stand | CRA: fortlaufend | nicht ersichtlich | [STANDARD] |
| CVE-Verweise (Sicherheit) | CRA-relevant | nicht ersichtlich | [STANDARD] — nicht Lizenz-Thema, aber CRA-Thema |
## Abschnitt 6 — Compliance-Status-Uebersicht
| Komponente | Compliance-Status | Hinweis |
|---|---|---|
| [[Modulname-8a3c-01]] | [PFLICHT-LUECKE] | MIT-Lizenz-Text-Mitlieferung im Vertrag nicht zugesichert |
| [[Modulname-8a3c-02]] | [PFLICHT-LUECKE] | Apache-NOTICE-Datei-Pflicht nicht adressiert |
| [[Modulname-8a3c-03]] | [STARK-COPYLEFT-WARNUNG] | GPL-2-only bei On-Premise — Quellcode-Pflicht ausgeloest, Faerbungs-Risiko |
| [[Modulname-8a3c-04]] | [ANWALT-PRUEFUNG] | LGPL-Linking-Form klaeren |
| [[Modulname-8a3c-05]] | [STARK-COPYLEFT-WARNUNG] | AGPL bei On-Premise — Quellcode-Pflicht ausgeloest; bei SaaS-Wechsel Network-Trigger |
| [[Modulname-8a3c-06]] | [PFLICHT-LUECKE] | BSD-3-Lizenz-Text und No-Endorsement nicht adressiert |
| [[Modulname-8a3c-07]] | [SBOM-LUECKE] | Lizenz nicht erkennbar — Klaerung mit [[Unternehmensname-8a3c]] |
| [[Modulname-8a3c-08]] | [PFLICHT-LUECKE] | MPL-Datei-basierte Copyleft-Pflicht im Vertrag nicht adressiert |
| [[Modulname-8a3c-09]] | [PFLICHT-LUECKE] | ISC-Lizenz-Text-Mitlieferung nicht adressiert |
## Abschnitt 7 — Indemnification-Hinweis
§ 7 des Vertrags schliesst eine Freistellung des Lizenznehmers
fuer Verletzungen der Open-Source-Lizenzen durch den Lizenzgeber
ausdruecklich aus. Das ist marktunueblich bei OSS-haltiger
Standard-Software. [ANWALT-PRUEFUNG: Indemnification-
Verhandlung mit [[Unternehmensname-8a3c]] empfohlen.]
[ANWALT-PRUEFUNG: Verteilungs-Bewertung im konkreten Konzern-
Setup (Anlage 2), Linking-Architektur fuer GPL/LGPL und
Indemnification-Strategie erfolgen anwaltlich auf Basis dieser
Matrix.]Was das Berufsrecht verlangt
Pflichten — und wie anymize sie abdeckt
§ 43a BRAO Verschwiegenheit
SBOMs enthalten neben Komponenten-Namen oft interne Repository-Pfade, Build-Identifier und Entwickler-Namen — also Mandanten-Internas, die das Geschäftsgeheimnis betreffen. anymize ersetzt 40+ Kategorien personenbezogener und geschäftsgeheimnis-relevanter Daten durch Platzhalter, bevor irgendein KI-Anbieter SBOM oder Vertragstext sieht. Erkennungsrate über 95 %.
§ 43e BRAO Auftragsverarbeitung
Sie schließen einen AVV mit anymize ab. Datenverarbeitung ausschließlich in deutschen Rechenzentren (Hetzner). Originaldokumente speichern wir nicht — nur die Zuordnung Platzhalter ↔ Originaldaten, mit Aufbewahrungsfrist nach Ihrer Wahl. Eine Selbstreferenz für IT-/IP-Kanzleien: Sie prüfen den Lizenzvertrag mit einem Werkzeug, das selbst nach § 43e BRAO ausgelegt ist.
§ 203 StGB Geheimnisschutz
Indem Mandantenname, Vendor-Identität und interne Modul-Bezeichnungen das Haus nicht verlassen, vermeiden Sie das Offenbarungsproblem grundsätzlich. Die anymize-Mitarbeitenden sind nach § 203 belehrt und sehen ohnehin nur die Zuordnungstabelle, nicht den Vertragstext.
Verteilungs-Begriff im OSS-Recht
Der Verteilungs-Begriff (Distribution) ist der Schlüssel des Copyleft-Rechts. GPL-Pflichten werden durch Verteilung ausgelöst — und SaaS-Bereitstellung gilt nach klassischer GPL-Auslegung nicht als Verteilung. AGPL v3 schließt diese Lücke durch den Network-Trigger. Bei On-Premise-Distribution greifen die Verteilungs-Pflichten vollumfänglich. Die KI strukturiert die Frage; die abschließende Bewertung im konkreten Setup ist anwaltlich.
Konzern-Privileg im OSS-Recht
Ob die Weitergabe innerhalb eines Konzerns (§§ 15 ff. AktG) als Verteilung i. S. der GPL gilt, ist umstritten. Die Free Software Foundation argumentiert, dass interne Weitergabe innerhalb derselben juristischen Einheit keine Verteilung sei — Tochtergesellschaften sind aber eigenständige juristische Personen. Die Praxis pragmatisiert über Konzern-Verträge mit Anerkennung der OSS-Lizenz-Bedingungen. Die KI markiert das mit [ANWALT-PRUEFUNG].
AGPL-Network-Trigger
AGPL v3 löst die Copyleft-Pflicht auch dann aus, wenn die Software über das Netzwerk bereitgestellt wird — unabhängig davon, ob klassische Verteilung vorliegt. Bei SaaS-Bereitstellung von AGPL-Komponenten muss der Quellcode den Network-Nutzern bereitgestellt werden. Bei On-Premise-Setup mit zukünftigem SaaS-Wechsel wird AGPL zur Falle — entweder AGPL-Komponente entfernen oder Quellcode-Bereitstellung implementieren.
Cyber Resilience Act (VO 2024/2847)
Der Cyber Resilience Act ist seit 11.12.2024 in Kraft, mit gestaffelten Anwendungs-Daten für Reporting-Pflichten (ab Mitte 2026) und für die Konformitäts-Anforderungen an Produkte (ab Ende 2027). Die SBOM-Pflicht ist eine der zentralen Anforderungen für Hersteller mit digitalen Elementen — Lizenz-Reviews bekommen dadurch zusätzlichen Auftrieb. Die KI markiert die SBOM-Vollständigkeit gegen CRA-Anforderungen; die Anwendbarkeits-Prüfung ist anwaltlich.
Indemnification gegen den Vendor
Marktüblich bei OSS-haltiger Standard-Software ist eine Indemnification-Klausel: Der Lizenzgeber stellt den Lizenznehmer von Ansprüchen Dritter aus OSS-Lizenz-Verletzungen frei. Wenn — wie im Beispielfall — die Freistellung ausdrücklich ausgeschlossen wird, trägt die Mandantschaft das Risiko vollständig selbst. Das ist Verhandlungsmasse. Die KI markiert; die Verhandlungs-Strategie ist anwaltlich.
Datenschutz und Vertraulichkeit
So funktioniert das mit anymize
Die juristisch entscheidende Frage beim Lizenz-Review: Sieht der KI-Anbieter den Mandantennamen, die Vendor-Identität und die internen Modul-Bezeichnungen? Antwort mit anymize: nein. Vendor- und Mandantenname, Adressen, Produkt- und Modul-Bezeichnungen, Repository-Pfade, Entwickler-Namen und Build-Identifier werden vor dem KI-Aufruf durch Platzhalter ersetzt; nach der KI-Antwort identifiziert anymize zurück. Verarbeitung in deutschen Rechenzentren (Hetzner), AVV nach Art. 28 DSGVO und § 43e BRAO ist Teil des Standardvertrags, Originaldokumente werden nicht gespeichert. Rechtsgrundlage Art. 6 Abs. 1 lit. b DSGVO (Mandatsvertrag); Art.-9-Anteile sind bei reinen Lizenz-Reviews selten relevant. Mandanten- und Vendor-Klarnamen werden aus dem KI-Kontext gehalten, was § 203 StGB strukturell entlastet. Die EDPB Opinion 28/2024 erkennt funktionale Anonymität gegenüber Cloud-Diensten an — anymize setzt diese funktionale Anonymität operativ um. Bei SBOMs mit Entwickler-Namen oder Repository-Pfaden kommt der Geschäftsgeheimnis-Schutz nach GeschGehG hinzu; auch diese Daten werden von anymize erkannt und ersetzt.
Was anymize konkret leistet
- Erkennt Mandanten- und Vendor-Klarnamen, Adressen, Produkt- und Modul-Bezeichnungen, Repository-Pfade, Entwickler-Namen und Build-Identifier mit über 95 % Genauigkeit.
- Ersetzt sie durch semantische Platzhalter, bevor der Vertragstext und die SBOM an GPT, Claude oder Gemini gehen.
- Re-identifiziert die KI-Antwort automatisch — Sie sehen die Lizenz-Matrix mit den richtigen Klarnamen zurück.
- Verarbeitung in deutschen Rechenzentren (Hetzner). AVV nach Art. 28 DSGVO mit § 43e BRAO-Erklärung im Standardvertrag.
- Originaldokumente werden nicht gespeichert — nur die Zuordnung Platzhalter ↔ Klarname, mit Aufbewahrungsfrist nach Ihrer Wahl von 24 Stunden bis unbegrenzt.
Sicherheitscheck vor der Einreichung
Was anymize liefert — was Sie souverän entscheiden
Vor dem KI-Aufruf
- Bereitstellungs-Form geklärt (On-Premise, SaaS, eingebettet)?
- Distribution an Dritte und Konzern-Setup beschrieben?
- Linking-Architektur dokumentiert (statisch/dynamisch/Plugin/IPC)?
- SBOM bereitgestellt — idealerweise CycloneDX oder SPDX?
- Anonymisierungs-Vorschau gesichtet — Stichproben bei großer Komponenten-Anzahl?
Nach der KI-Antwort
- Re-Identifikation korrekt — alle Platzhalter zurückgesetzt?
- Lizenz-Matrix vollständig — alle sechs Abschnitte abgedeckt?
- [STARK-COPYLEFT-WARNUNG]-Komponenten anwaltlich nachgeprüft?
- [ANWALT-PRUEFUNG]-Markierungen abgearbeitet (Verteilungs-Begriff, Linking, Konzern-Privileg)?
- [SBOM-LUECKE]-Komponenten zur Klärung an Vendor adressiert?
Vor der Mandanten-Empfehlung
- Verteilungs-Bewertung im konkreten Setup anwaltlich verantwortet?
- Konzern-Privileg-Frage (Tochtergesellschaften) geklärt?
- Indemnification-Verhandlungs-Strategie formuliert?
- Bei AGPL-Komponenten: SaaS-Wechsel-Risiko adressiert?
- Folge-Mandate identifiziert (Lizenz-Bereinigung, Indemnification-Verhandlung, CRA-Compliance-Beratung)?
Typische Fehlermuster — und wie anymize gegensteuert
- →KI gibt Verteilungs-Bewertung im konkreten Setup ab — der Prompt verbietet das, prüfen Sie die Markierung.
- →KI verwechselt GPL-2-only und GPL-2-or-later — die Versions-Klausel entscheidet bei Kompatibilitäts-Fragen.
- →KI behauptet, AGPL und GPL seien identisch — der Network-Trigger ist die zentrale Erweiterung der AGPL.
- →KI markiert „see LICENSE file“-Komponenten als zugeordnet, obwohl die Datei nicht beigefügt ist — das ist eine SBOM-Lücke, nicht eine Lizenz-Zuordnung.
- →KI gibt Konzern-Privileg pauschal als „erlaubt“ aus — der Streitstand ist nicht eindeutig.
- →KI verweist auf veraltete Lizenz-Praxis vor MPL 2.0 oder CDDL-Updates — Versions-Klarheit prüfen.
Rechtsgrundlagen
Normen, Urteile, Belege
Primärnormen
- insbesondere Art. 13 ff. (SBOM-Pflichten Hersteller)
- GNU General Public License (Free Software Foundation)
- GNU Affero General Public License — Network-Trigger
- GNU Lesser General Public License
- Apache Software Foundation
- Permissive Lizenz
- Permissive Lizenz
- Mozilla Public License — Datei-basierte Copyleft
Berufsrechtliche Grundlagen
- Anwaltliche Verschwiegenheit
- Auftragsverarbeitung und IT-Auslagerung
- Verletzung von Privatgeheimnissen
- Geschäftsgeheimnis-Schutz
Sekundärquellen
- OWASP SBOM-Standard
- ISO/IEC 5962:2021 SBOM-Standard
- Cyber-Resilienz-Anforderungen
- SBOM-Anforderungen US-Bundes-Beschaffung
- Free Software Foundation — GPL-Praxis
- Mandantentransparenz und KI-Einsatz
- OSS-Compliance-Management
Stand: · Nächste Überprüfung:
Hinweis zur Nutzung
Zur Orientierung — nicht als Mandatsersatz
Diese Anleitung beschreibt einen Arbeitsablauf, den Sie mit anymize umsetzen können. Sie ist zur Orientierung gedacht und ersetzt weder die anwaltliche Würdigung im Einzelfall noch eine fachanwaltliche Prüfung. Welche Rechtsprechung einschlägig ist, wie der Sachverhalt rechtlich zu bewerten ist, welche Anträge in Ihrem konkreten Mandat richtig sind — das bleibt selbstverständlich bei Ihnen.
KI-Outputs müssen vor jeder Verwendung anwaltlich geprüft werden. Insbesondere Urteils-Aktenzeichen, Norm-Verweise und Fristen sind gegen Primärquellen zu verifizieren. anymize gewährleistet die Vertraulichkeit der Mandantendaten gegenüber dem KI-Anbieter; die fachliche Richtigkeit des Outputs liegt in Ihrer Verantwortung.
Jetzt starten.
14 Tage kostenlos testen.
Alle Modelle. Alle Features. Keine Kreditkarte.
Wir sind überzeugt von anymize. Und wir wissen: Bei einem KI-Werkzeug, das Mandanten-, Patienten- oder Mitarbeiter-Daten berührt, reicht ein Demo-Video nicht. Deshalb 14 Tage voller Zugang – alle Modelle, alle Features, keine Kreditkarte. Genug Zeit, um sicher zu sein, bevor du uns vertraust.
Dein KI-Arbeitsplatz wartet.