How to review a third-party inventory before publish

Because import only tells you what is there, not whether the license metadata is trustworthy: Package registries mislabel licenses, vendors change terms, and transitive dependencies introduce copyleft you did not expect. A third-party inventory file is input, not a finished compliance page.

The scale is documented, and it is exactly the set of cases automated import cannot resolve on its own.

Review gates exist so you cannot publish a license compliance URL that overstates what your team verified. Procurement and auditors treat the public page as your representation of third-party license obligations.

Start from artifacts tied to the build you ship: package-lock.json, pnpm-lock.yaml, yarn.lock, go.mod, Cargo.lock, pom.xml, Gemfile.lock, a CycloneDX SBOM from CI, or exports from your existing SBOM tool. Mark every row needs review until someone confirms the license.

Scope the import to one product. Multi-product companies need separate license compliance pages, or clearly separated sections, per shipped product. Mixing inventories creates disclosure errors.

• Import lockfiles or SBOMs from the release branch, not main if it diverges.
• Include fonts, icons, SDKs, and embedded assets your policy requires.
• Flag duplicates and merge entries that refer to the same component.
• Record import date and source file hash for audit trail.
• Do not auto-publish. Every entry starts unreviewed.

For each line, confirm the license identifier matches actual usage, not just package.json metadata. Read copyleft triggers. Attach full license text. Document exclusions explicitly.

Reviewers focus on GPL, LGPL, AGPL, proprietary SDKs, and components with missing or conflicting license data. Those rows block publish until resolved.

• Match license to source: Repo LICENSE file, vendor agreement, or SPDX identifier confirmed by a human.
• Add full license text to the record before marking approved.
• Flag copyleft, network copyleft (AGPL), and custom licenses for legal or senior engineering review.
• Resolve conflicts (registry says MIT, repo says Apache) before approve.
• Document components excluded from the shipped product and why.
• Require a second approver for high-risk licenses if your policy defines one.

Publish only when gates pass: No unreviewed rows, full license text attached, product scope clear, URL stable. The public license compliance page is the same data as your exports. One reviewed inventory, multiple outputs.

Third-party license disclosure pages should load without authentication, list components clearly, and include full license text procurement can search and copy. That is what enterprise reviews look for.

• Block publish if any in-scope component lacks approved license text.
• Generate public URL and verify in incognito before sharing externally.
• Export JSON, attribution, and disclosure bundles from the same approved snapshot.
• Record who approved publish and which release tag it matches.

License compliance is not one-and-done. New dependencies, version bumps, and license changes arrive every sprint. Drift checks compare current lockfiles or SBOMs to your last approved publish and flag differences before customers notice.

When inventory changes, re-run review gates. Update the license compliance page. Send updated URLs to procurement only when the new publish is approved, not when import finishes.

• Run pipeline or CI checks on pull request, tag, or release.
• Flag new unreviewed packages before release, per your policy.
• Re-approve copyleft components when linking or distribution model changes.
• Keep audit trail: Import, review, publish, drift events.