0107Workflow
Von unbekannten Pflichten zu verteidigungsfähigem Nachweis
Fünf kontrollierte Schritte (Import, Prüfung, Veröffentlichung, Export, Steuerung), damit das ausgelieferte Artefakt jedes Repositorys dem entspricht, was seine Attestierungsseite zeigt.
Zuletzt aktualisiert: 2. Juli 2026
Die fünf Schritte
Lizenzpflichten pro Release operationalisieren
Keine bequeme Zusatzschicht über npm: ein kontrollierter Weg, damit das ausgelieferte Artefakt jedes Repositorys dem entspricht, was seine Compliance-Seite und Exportdateien darstellen.
Erfassen, was Pflichten erzeugt
Importieren Sie per Repository-Auto-Sync oder laden Sie CycloneDX SBOM, npm (package-lock.json), pnpm (pnpm-lock.yaml), Yarn (yarn.lock), Bun (bun.lock), Go (go.mod), Rust (Cargo.lock), Python (uv.lock, poetry.lock), NuGet (packages.lock.json), Maven (pom.xml), Gradle (gradle.lockfile), Composer (composer.lock), Bundler (Gemfile.lock) hoch. Jede Zeile ist eine Lizenz, die Sie erfüllen müssen. Fügen Sie Schriftarten, Icons, SDKs und manuelle Einträge hinzu, die automatisierte Importe übersehen. Nichts ist „erledigt“, bevor ein Mensch die Lizenz bestätigt; Importe beginnen als prüfungsbedürftig.
Pflichten pro Paket prüfen
Gleichen Sie Lizenzen im SPDX-Stil ab, nicht rohe Manifest-Zeichenketten. Rufen Sie Lizenztext automatisch ab, geben Sie unbedenkliche Lizenzen in Sammelaktion frei, und lassen Sie Copyleft- und Verbreitungsrisiko aus dem Katalog sichtbar werden. Vollständiger Lizenztext ist vor der Veröffentlichung für hinweispflichtige Bedingungen erforderlich. Externe Pflichten müssen bestätigt werden, sonst wird die Veröffentlichung gesperrt.
Eine Attestierungsseite pro Projekt veröffentlichen
Jedes Projekt erhält eine gebrandete öffentliche Attestierungsseite aus dem geprüften Bestand; verlinken Sie sie aus Dokumentation, Trust Centern und Ausschreibungsantworten. Nur freigegebene Pakete mit vollständigem Lizenztext erscheinen. Die Veröffentlichung ist gesperrt, bis Ihr Team verifiziert hat, was Sie darstellen.
Konforme Dateien herunterladen, wenn Sie sie brauchen
Erzeugen Sie Offenlegung, NOTICE, JSON, PDF, CycloneDX und SPDX-Exporte aus demselben eingefrorenen Snapshot wie die Live-Seite. Laden Sie sie in Repositories, hängen Sie sie an Releases an, oder archivieren Sie sie für Audits. Exporte enthalten Herkunftsnachweis und, sofern veröffentlicht, die öffentliche URL.
Pflichten produktübergreifend steuern
Organisationsweites Compliance-Dashboard, projektübergreifende Bestandssuche und Audit-Trail für compliance-relevante Änderungen. Veröffentlicht- vs. Test-Branch-Spuren für verbundene Projekte. Lizenzkatalog gepflegt ohne erneutes Deployment.
Die Seite und die Exporte jedes Projekts beschreiben nur dieses Produkt. Pflichten greifen nicht auf andere Projekte über. Exportdateien ansehen →
Lizenz-Intelligence
Gleiche Lizenz, andere Pflicht. Die Warnungen wissen, wie Sie ausliefern.
Sie geben an, wie das Produkt verbreitet wird: gehosteter Dienst, ausgelieferte Binärdatei, Bibliothek oder eine Mischung. Diese Wahl ändert, welche Kompatibilitätswarnungen und Pflichten erscheinen, denn AGPL in einem SaaS-Backend ist eine andere rechtliche Frage als AGPL in einem internen Tool.
- Warnungen nur für Muster, die reale Streitfälle verursacht haben: AGPL und SSPL in SaaS, GPL in ausgelieferten Binärdateien, BUSL, Elastic 2.0 in Managed Services, OFL-Schriftarten
- Dedupliziert: Zwanzig AGPL-Pakete erzeugen eine Warnung, nicht zwanzig
- Relizenzierungs-Beobachtung: Markiert Abhängigkeiten, die innerhalb bekannter Lizenzwechsel-Zeitfenster fixiert sind, etwa Redis zu AGPL oder HashiCorp zu BUSL
Geführte Prüfung
Prüfung ist ein geführter Ablauf, keine Tabellen-Plackerei.
Die meisten Pakete klären sich von selbst; Ihr Urteilsvermögen bleibt der Handvoll vorbehalten, die es braucht. Und ein Paket geht erst live, wenn seine Lizenz bestätigt, sein Text hinterlegt und jede zutreffende Pflicht abgehakt ist.
Unbedenkliche automatisch freigeben
Ein Klick gibt jedes freizügige Paket mit verifiziertem Text und ohne offene Pflichten frei und sagt genau, warum der Rest übersprungen wurde.
138 Pakete automatisch freigegeben · 4 benötigen Aufmerksamkeit
Ein Assistent für den Rest
Ein Paket nach dem anderen, mit Fortschrittsbalken und den Optionen Freigeben, Überspringen oder Zurückstellen. Jedes zeigt eine verständliche Situationskarte: was das System erkannt hat, und die eine nächste Handlung.
Pflichten werden zu Checkboxen
Lizenzrecht gliedert sich in Hinweise, die wir für Sie darstellen, und manuelle Schritte, die nur Ihr Team ausführen kann, jeweils mit einer Erklärung, was das für Sie bedeutet. Der Veröffentlichen-Button bleibt gesperrt, bis sie abgehakt sind.
Stellen Sie den Quellcode bereit, wenn Sie dieses Paket an Kunden ausliefern
Import-Vorschau, bevor irgendetwas übernommen wird
Jeder Import klassifiziert Pakete zunächst als neu, aktualisiert oder unverändert, sodass Sie genau sehen, was ankommen wird.
12 neu · 3 aktualisiert · 40 unverändert
Doppellizenzen, gelöst
Bei MIT-ODER-Apache-2.0-Paketen wählen Sie den Zweig, den Sie tatsächlich nutzen, vorausgewählt anhand dessen, was im Artefakt ausgeliefert wurde, und die Pflichten richten sich nach Ihrer Wahl.
Team-Notizen, die intern bleiben
Prüfer hinterlassen Kommentare zu Paketen für den nächsten Prüfer. Sie erscheinen nie auf der öffentlichen Seite.
Liefern Sie nicht länger auf Verdacht aus
Erfassen Sie Ihre Pflichten vor dem nächsten Release
Legen Sie ein Projekt für jedes Repository an, prüfen Sie Ihre Pflichten, veröffentlichen Sie, wenn Sie bereit sind, und halten Sie den Nachweis bei jedem Release aktuell. Laden Sie Lizenz- und Namensnennungsdateien herunter, wenn Engineering sie braucht, mit Pipeline-Prüfungen, damit das nächste Update nicht zunichtemacht, was Sie bereits freigegeben haben. Ihr SOC-Bericht ist kein Ersatz.
Noch nicht bereit anzufangen? View pricing