0107Workflow
From unknown obligations to defensible proof
Five controlled steps (import, review, publish, export, govern) so each repo's shipped artifact matches what its attestation page represents.
Last updated: July 2, 2026
The five steps
Operationalize license duties per release
Not a convenience layer on top of npm: A controlled path so each repo’s shipped artifact matches what its compliance page and export files represent.
Inventory what creates obligations
Import from repo auto-sync or upload 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). Each row is a license you must satisfy. Add fonts, icons, SDKs, and manual entries automated imports miss. Nothing is “done” until a human confirms the license; imports start as needs review.
Review obligations per package
Match SPDX-style licenses, not raw manifest strings. Auto-fetch license text, bulk-approve safe licenses, and surface copyleft and distribution risk from the catalog. Full license text is required before publish for notice-bearing terms. External duties must be acknowledged or publish is blocked.
Publish an attestation page per project
Each project gets a branded public attestation page from reviewed inventory; link from docs, trust centers, and RFP responses. Only approved packages with complete license text appear. Publish is blocked until your team has verified what you represent.
Download compliant files when you need them
Generate disclosure, NOTICE, JSON, PDF, CycloneDX, and SPDX exports from the same frozen snapshot as the live page. Download into repos, attach to releases, or archive for audits. Exports include provenance and the public URL when published.
Govern obligations across products
Org-wide compliance dashboard, cross-project inventory search, and audit trail for compliance-relevant changes. Published vs Testing branch lanes for connected projects. License catalog maintained without redeploy.
Each project’s page and exports describe that product only. Obligations do not bleed across projects. See export files →
License intelligence
Same license, different duty. The warnings know how you ship.
You declare how the product is distributed: Hosted service, shipped binary, library, or a mix. That choice changes which compatibility warnings and obligations appear, because AGPL in a SaaS backend is a different legal question than AGPL in an internal tool.
- Warnings only for patterns that have caused real disputes: AGPL and SSPL in SaaS, GPL in shipped binaries, BUSL, Elastic 2.0 in managed services, OFL fonts
- Deduplicated: Twenty AGPL packages produce one warning, not twenty
- Re-licensing watch: Flags dependencies pinned inside known license-change windows, like Redis to AGPL or HashiCorp to BUSL
Guided review
Review is a guided flow, not a spreadsheet slog.
Most packages clear themselves; your judgment is saved for the handful that need it. And a package cannot go live until its license is confirmed, its text is on file, and every applicable obligation is ticked.
Auto-approve safe defaults
One click clears every permissive package with verified text and no open obligations, and says exactly why it skipped the rest.
Auto-approved 138 packages · 4 need attention
A wizard for the rest
One package at a time with a progress bar and Approve, Skip, or Park. Each shows a plain-language situation card: What the system saw, and the single next action.
Obligations become checkboxes
License law splits into notices we render for you and the manual steps only your team can take, each with a what-this-means-for-you explainer. The Publish button stays gated until they're ticked.
Share the source if you ship this package to customers
Import preview before anything commits
Every import classifies packages as new, updated, or unchanged first, so you see exactly what will land.
12 new · 3 updated · 40 unchanged
Dual licenses, handled
For MIT OR Apache-2.0 packages you pick the arm you actually use, pre-selected from what shipped in the artifact, and the obligations follow your election.
Team notes that stay internal
Reviewers leave comments on packages for the next reviewer. They are never rendered on the public page.
Continue reading
Related topics
One idea per page: Follow the path that matches your next question.
Stop shipping on assumptions
Map your obligations before the next release
Set up a project for each repo, review your obligations, publish when ready, and keep the record aligned with every release. Download license and attribution files when engineering needs them, with pipeline checks so the next update does not undo what you already approved. Your SOC report is not a substitute.
Not ready to start yet? View pricing