What procurement actually asks for

Because products are not frozen at a version: Engineers merge dependency updates, add SDKs, swap fonts, and bump transitive packages, often without one person tracking the full obligation picture. You cannot reliably say "this is everything running in production right now" from a spreadsheet you built months ago.

A PDF, zip file, or SBOM attachment is a snapshot. The moment someone ships a release with new packages, that snapshot is historical. Not wrong maliciously, just outdated. Procurement files it, assumes it is current, and discovers the gap months later in an audit or renewal.

The real requirement is not "send a URL instead of a PDF." You need a reviewed inventory tied to what you ship, updated when dependencies change, and shared only after publish gates pass. A public compliance page is one way to host that record so both sides see the same version. Links are not magic; the record behind them is meant to be updated.

They want evidence that you have operational control over third-party license obligations, not that you once ran npm list on a laptop. Different questionnaires use different words (open-source license page, third-party software list, OSS disclosure, software bill of materials plus license text), but the intent is similar.

A software bill of materials alone often does not satisfy the request. An SBOM's minimum elements, as defined by the U.S. NTIA, center on component identity for vulnerability and inventory use, not reviewed license disclosure. Procurement and legal reviewers still want full license text and some confirmation that the list stays aligned with releases.

• Reviewed third-party and open-source inventory for the product under review.
• Full license text or reliable links, not SPDX identifiers without text.
• Attribution and notice where licenses require them.
• Clarity on which product, release, or date the disclosure reflects.
• Often a URL, export, or attachment, whichever their process specifies.
• Increasingly: How you keep the record current when dependencies change.

Do not send your corporate marketing site license footer if the buyer is evaluating your API product, mobile app, or on-prem installer. Each shipped product may need its own disclosure record, or a clearly scoped section.

Ask which SKU, product name, version, or release date the review covers. License compliance is product-specific. Sending documentation for the wrong product creates more rework than sending nothing.

• Which product or SKU is under review?
• Which version, release tag, or date should the disclosure reflect?
• Do they want a URL, an export file, or both?
• Is the review for SaaS, installable software, embedded, or all delivery models?
• Who is the audience: Procurement, legal, security, or all three?

Before you reply, confirm the record matches the build customers receive. Not main branch, not a developer's local machine, not an inventory nobody has reviewed since last quarter.

In a multi-person team, dependencies shift without central notice. One engineer bumps a patch version; another adds an analytics SDK; a transitive package changes license metadata in the registry. Without import, review, and publish gates, nobody knows the disclosure is stale until a buyer asks.

Compare your disclosure to the lockfile, SBOM, or export from the release under review. Spot-check copyleft components, commercial SDKs, and anything marked needs review. If you cannot verify each line, fix the gap or be honest about timeline.

• Import from the release branch or CI artifact, not an outdated manual list.
• Confirm every in-scope component has approved license text.
• Resolve unreviewed rows before you represent the record externally.
• Check that the product name on the disclosure matches what the buyer is purchasing.
• Note the release tag or date the inventory reflects, and say so in your reply.

Send what they asked for (URL, PDF export, JSON bundle) from the same approved publish snapshot. State which product and release it covers. Describe briefly how you update the record when dependencies change: Re-import, re-review, re-publish.

Do not imply legal sign-off unless counsel approved it. Do not say "this is everything in our stack forever." Say what was reviewed, for which product, as of which release, and that you maintain the record as the codebase changes.

If the record is not ready, give a realistic date. Procurement prefers honesty over a snapshot that fails review because someone merged five dependency updates since you generated it.

• Lead with product name and "third-party license disclosure" or "open-source license compliance."
• State the release, tag, or date the inventory reflects.
• Provide the URL or attachment they requested, from the same reviewed data.
• One sentence on maintenance: How you re-publish when dependencies change.
• Offer exports if the questionnaire requires them, generated from the same snapshot.

Exporting a list once and reusing it across releases. Assuming nobody added packages since the last RFP. Sending a raw SBOM without reviewed license text. Sending a trust center PDF about security that never lists third-party licenses.

Claiming SOC 2 or ISO 27001 covers open-source license obligations (it usually does not). Treating "we use open source" as disclosure. Each of these fails when the buyer compares your answer to what actually ships, or what shipped two sprints after you replied.

The fix is operational: Inventory from build inputs, human review before external share, update on dependency change. Not a better file format.