License compliance checklist: what to verify before you share proof

A strong page identifies the shipped product, lists third-party components with reviewed licenses, includes full license text or reliable links, and shows attribution where licenses require it. Procurement and auditors expect more than a list of npm packages.

If your page only says "we use open source" without inventory, license text, or a clear scope, it will not satisfy a third-party license disclosure request. That holds even when engineering passed an internal security review.

The need is broad: Black Duck's 2025 Open Source Security and Risk Analysis found that 97% of audited codebases contained open source, so almost every product carries third-party obligations whether or not they are documented.

• Product name and version (or release channel) the page covers.
• Third-party and open-source component inventory, direct and transitive where your process requires it.
• SPDX-style or equivalent license identifiers, after human review, not registry guesses alone.
• Full license text for each component, or stable links that resolve to full text.
• Attribution and notice blocks where MIT, Apache, BSD, GPL, or custom licenses require them.
• Clear labeling if the page is example, beta, or production, where relevant.

License compliance starts with inventory: Every component on your compliance page should match the current shipped build, not a dev branch, not staging, not a product line you are not selling yet.

Teams often miss fonts, icon packs, analytics SDKs, embedded JavaScript on marketing sites, and transitive dependencies pulled in by a single direct import. Compliance fails quietly when the inventory is incomplete. Black Duck's 2025 OSSRA reports that transitive dependencies caused nearly 30% of the license conflicts it found, so a checklist that stops at direct imports misses a large share of risk.

• Every component in the page matches the build customers receive today.
• Transitive npm, pnpm, yarn, Go, Rust, Python, Java, .NET, PHP, or Ruby dependencies are included per your policy.
• Fonts, icons, images with license terms, and commercial SDKs are not skipped.
• Container base layers and bundled native libraries are in scope if you distribute them.
• Items marked unknown or needs review are resolved or explicitly excluded with documented reason.
• The inventory source (lockfile, CycloneDX SBOM, manual entry) is traceable to the release.

It requires reviewers to be able to read the actual license, not a summary: Third-party license disclosure means full license text per component. Procurement and legal compare your page against the obligations in GPL, LGPL, Apache, MIT, and proprietary SDK agreements.

Attribution is separate from notice and separate from full license text. A page that lists "MIT" without the MIT license text or required copyright notice is incomplete for most enterprise reviews.

• Each component has an identified license, reviewed by a human, not copied blindly from package metadata.
• Full license text is present on the page or linked without login walls or expiring URLs.
• Copyleft components (GPL, AGPL, LGPL, etc.) have passed your internal review gates.
• Attribution wording matches what each license requires, not a generic "open source licenses" footer.
• Dual-licensed or custom components have an explicit decision recorded.
• No component is published as approved until license text is attached or linked.

A license compliance page is a living record. The URL procurement saved in their vendor file should still be accurate after your next release. Compliance breaks when the page drifts from what ships.

Publish gates (review before publish) prevent teams from claiming compliance they have not verified. Exports (JSON, attribution files, disclosure bundles) should match the same reviewed inventory as the public URL.

• A named owner approved publish for this product and release.
• The compliance page URL is stable, public, and reachable without authentication.
• Exports and release bundles match the published inventory.
• Drift checks or pipeline checks flag new packages before the next customer audit.
• You have a documented process to update the license page when dependencies change.
• You do not imply legal sign-off unless counsel has reviewed. The page is an operational record.

Open the license compliance page in an incognito window. Confirm it loads, identify the product, and spot-check five random components against your internal inventory. If procurement asks for proof, this is what they will do.

When the checklist passes, send whatever format they asked for (URL, export, or attachment) from the same reviewed publish snapshot. Name the product and the release or date it reflects. The file type matters less than whether the inventory was reviewed and approved before you sent it.

No. An SBOM checklist confirms component identity in a machine-readable format. A license compliance checklist confirms reviewed licenses, full text, attribution, and a publish state you are willing to share. You often need both, in that order.

Re-run it before any external share, and again whenever dependencies change on a watched release branch. Drift between the last approved publish and the current lockfile is the usual failure mode.

Pick one accountable owner per product, usually engineering with legal review on high-risk licenses. Shared ownership without a publish gate is how stale URLs end up in vendor files.