Know what your dependencies require before you distribute them.
ShipGate identifies the components in your release's distribution closure, maps their licences to your declared distribution model, checks required notices, and prepares the mechanical fixes it safely can. No licence-risk score — every result shows what was observed, what you declared, what rule was derived, and what still needs human review.
Witness an already-published npm package tarball by SHA-256. ShipGate downloads the exact .tgz, opens it without executing it, and reports what is physically inside — bundled components are Observed in artifact; runtime dependencies named but not carried stay Assumed. This is where a licence blocker is backed by the distributed bytes, not a lockfile guess.
Or witness a GitHub Release asset by SHA-256 — one asset, one receipt (a release label is intent; the artifact hash is evidence). Archive assets only in v0.1 (.zip, .tar.gz).
What is this release?
Obligations attach to an act of distribution, not to a repository. These declarations decide which obligations can be derived at all.
If the repo is a pnpm monorepo whose root has no production dependencies, name the workspace you actually release (e.g. packages/cli). ShipGate gates that importer's production graph. Leave empty otherwise.
Computing distribution closure…
Reading lockfile, identifying licences from lockfile metadata and the npm registry…
Distribution closure
| Component | Licence | Evidence | Relationship | Result |
|---|
ShipGate prepares release-readiness evidence and artefacts. It does not provide legal advice or determine whether a particular software combination infringes a licence. Ambiguous licence scope, derivative-work, linking and compatibility questions are surfaced for review rather than decided automatically.