Source: [AI-suggested dependencies: retain license evidence before approval — Skills for Business](<https://skillsforbusiness.ai/blog/ai-suggested-dependencies-license-evidence/>)

[← All articles](https://skillsforbusiness.ai/blog/)

Development · Guide

# AI-suggested dependencies: retain license evidence before approval

Review license evidence for the exact software release an AI coding assistant proposes. Preserve declarations, file notices and unresolved questions separately.

[Skills for Business](https://skillsforbusiness.ai/blog/editorial/)5 November 20267 min read

On this page

1.  [Establish the release before collecting its license evidence](https://skillsforbusiness.ai/blog/ai-suggested-dependencies-license-evidence/#establish-the-release-before-collecting-its-license-evidence)
2.  [A declaration is a starting point, not the whole inspection](https://skillsforbusiness.ai/blog/ai-suggested-dependencies-license-evidence/#a-declaration-is-a-starting-point-not-the-whole-inspection)
3.  [Preserve the relationships inside a license expression](https://skillsforbusiness.ai/blog/ai-suggested-dependencies-license-evidence/#preserve-the-relationships-inside-a-license-expression)
4.  [Work through a fictional chart-library intake](https://skillsforbusiness.ai/blog/ai-suggested-dependencies-license-evidence/#work-through-a-fictional-chart-library-intake)
5.  [Keep evidence discovery separate from the approval decision](https://skillsforbusiness.ai/blog/ai-suggested-dependencies-license-evidence/#keep-evidence-discovery-separate-from-the-approval-decision)
6.  [Carry the decision into the release and revisit changed scope](https://skillsforbusiness.ai/blog/ai-suggested-dependencies-license-evidence/#carry-the-decision-into-the-release-and-revisit-changed-scope)
7.  [Sources](https://skillsforbusiness.ai/blog/ai-suggested-dependencies-license-evidence/#sources)

What to take away

-   Tie license evidence to the exact dependency release and intended use, rather than a general project label.
-   Keep package declarations, file-level findings and approval decisions distinct.
-   Preserve complete license expressions and route unresolved scope or interpretation to the responsible reviewer.

When an AI coding assistant proposes a dependency, retain the license evidence for the exact release before treating it as approved for your application. Record what the package declares, what its included files say, and what the responsible reviewer decided for the intended use. Those are separate facts. An assistant’s summary that a project is “open source” does not resolve them.

This guide is for developers and business owners reviewing AI-assisted software changes. It proposes an evidence handoff, not a legal determination of license compatibility or obligations. Questions about interpreting terms belong with the organization’s designated open-source or legal reviewer. The example below is fictional; we have not scanned a real dependency or tested an AI product for this article.

## Establish the release before collecting its license evidence

Our [dependency identity guide](https://skillsforbusiness.ai/blog/ai-suggested-dependencies-identity-check/) addresses whether an AI-suggested package is the project you intended to obtain. License review comes after that identity check. Record the ecosystem, distribution name, resolved version and source of the release artifact. Keep the artifact checksum or another reproducible identifier where your normal dependency process supplies it.

A project homepage is useful context, but the current repository branch may differ from an older installed release. A source archive, installed distribution and bundled application also answer different questions. State which artifact the evidence describes so the next reviewer can reproduce the inspection.

Write down the proposed use in concrete terms: a build tool, a server component, code included in a browser bundle or a library supplied with a customer download. This records technical facts for review. It does not decide their legal consequences. If that use changes, the old decision may no longer answer the new question.

## A declaration is a starting point, not the whole inspection

The [npm package.json documentation](https://docs.npmjs.com/cli/v11/configuring-npm/package-json/) defines a `license` field that can contain an SPDX identifier or expression. It also documents `SEE LICENSE IN <filename>` for a custom license or one without an assigned identifier, with the referenced file included in the package. A manifest value can therefore point to further evidence rather than contain the complete terms.

Keep the raw declaration and the referenced file together. Do not have the assistant replace an unfamiliar value with the nearest familiar license name. If the referenced file is absent from the artifact under review, record that missing evidence and seek clarification through the team’s normal process.

Philippe Ombredanne’s [October 2020 IEEE Computer article](https://dirkriehle.com/wp-content/uploads/2020/10/09206429.pdf) distinguishes extracting declared metadata, detecting license notices in files, and matching code to external sources. It explains that top-level declarations can be incomplete or inconsistent with file-level information. This is a historical tooling review by a ScanCode author, not a current benchmark of AI assistants. We use those distinctions, not its historical package-clarity percentages, to structure the proposed handoff.

A detected notice also needs context. Preserve the path and the finding instead of immediately replacing the package’s declared value with one scanner label. The reviewer needs to know whether the finding concerns included library code, a test fixture, an example or another artifact.

## Preserve the relationships inside a license expression

The [SPDX v2.3.1 license-expression specification](https://spdx.github.io/spdx-spec/v2.3.1/SPDX-license-expressions/) uses `OR` to represent a choice, `AND` for simultaneous requirements and `WITH` for an exception associated with a license. Parentheses preserve grouping. These are specification semantics; they do not establish which expression correctly describes an arbitrary software artifact.

For an evidence record, retain the complete expression as supplied. An AI-generated summary such as “MIT and Apache” loses whether the source said `MIT OR Apache-2.0` or `MIT AND Apache-2.0`. The two strings express different relationships. Do not collapse them to a bag of license names and then ask a reviewer to reconstruct the original meaning.

Likewise, keep an exception with the expression it qualifies. A shortened dashboard label may help navigation, but the evidence view should expose the original string and its source. Flag malformed or ambiguous expressions rather than silently repairing them and presenting the repair as the publisher’s declaration.

## Work through a fictional chart-library intake

Imagine a fictional team adding a chart-rendering dependency to a customer-facing reporting application. Its package metadata declares MIT. The release archive also contains a `vendor/` directory with a separate notice for a bundled renderer. The generated pull-request description says, “MIT licensed; approved for commercial use.”

The problem is not that the fictional second notice proves a conflict. It is that the summary has jumped from one declaration to an approval covering the whole proposed use. The reviewer has not yet established the bundled renderer’s scope, how it reaches the delivered application or what the team needs to do about it.

Our proposed handoff would preserve these separate entries:

| Evidence item | What the record says | What remains unresolved |
| --- | --- | --- |
| Exact package release | Resolved version, artifact source and checksum | Whether the inspected artifact matches the build input |
| Package declaration | Literal MIT value and its location | Whether it describes all included material |
| Bundled renderer notice | Exact path, text or stable reference | Which files it covers and whether they enter the deliverable |
| Intended use | Chart code included in the customer-facing application | Consequences under the applicable terms and team policy |
| Decision | Pending designated review | Conditions, owner and evidence needed to close the review |

This table is an invented review case, not a finding about a named package. The useful result is an inspectable question. It gives a developer a concrete build investigation and gives the designated reviewer the facts needed for interpretation.

If the renderer is excluded, verify that claim against the actual build rather than the import statement alone. If it is included, preserve the relevant notice and record the resulting decision through the established process. Neither outcome should be invented by the assistant to make the pull request appear complete.

## Keep evidence discovery separate from the approval decision

An assistant can help organize candidate evidence, compare declared values across revisions and draft a list of unresolved findings. Require each extracted claim to point to the inspected artifact and location. Give the reviewer the original text alongside the summary so omissions and changed scope remain visible.

Use separate statuses for evidence collected, questions unresolved and accepted for the stated use. A scanner finishing successfully means its operation completed; it does not mean the dependency has passed every review your organization requires. Similarly, finding a license identifier is different from satisfying the team’s documented release conditions.

Haksung Jang’s [June 2026 practitioner analysis](https://haksungjang.github.io/en/blog/2026/06/08/ai-generated-code-how-far-should-open-source-scanning-go/) distinguishes dependency inspection from snippet-level matching for code fragments not declared as packages. That distinction helps define this guide’s boundary. A dependency evidence record does not account for every copied or generated fragment elsewhere in the application. We do not adopt the post’s legal conclusions or litigation-status discussion as advice here.

Keep security and behavioral checks separate too. A dependency can have clear license evidence while still being vulnerable, unsuitable or incorrectly used by generated code. Conversely, passing an application test cannot resolve missing license evidence.

## Carry the decision into the release and revisit changed scope

When the responsible reviewer accepts the dependency, record the artifact and use covered, any required release work, the decision owner and the supporting evidence. Check completion of that release work against the artifact that will actually be delivered. Do not treat adding a review note as proof that the required files or notices reached the release.

For a small team, the record may fit in a pull request with links to retained evidence. A larger organization may store it in its component inventory and review system. Preserve the same distinctions at either scale; a larger spreadsheet does not compensate for an unclear scope.

Revisit affected evidence when the dependency version, bundled files, build path or delivery arrangement changes. An earlier decision should be reusable where its assumptions remain true, but it should not become blanket approval for all future versions and uses.

Start with one recent AI-assisted dependency addition. Ask another developer to locate the exact inspected release, reconstruct the declaration and file-level findings, and identify the recorded decision. If they cannot, improve that evidence handoff before accelerating the next dependency change.

## Sources & further reading

Sources checked for this article. Research findings and vendor claims are distinguished in the text.

1.  [package.json — license](https://docs.npmjs.com/cli/v11/configuring-npm/package-json/)npm Docs · Accessed 5 November 2026
2.  [Annex D: SPDX license expressions](https://spdx.github.io/spdx-spec/v2.3.1/SPDX-license-expressions/)SPDX Specification v2.3.1 · Accessed 5 November 2026
3.  [Free and Open Source Software License Compliance: Tools for Software Composition Analysis](https://dirkriehle.com/wp-content/uploads/2020/10/09206429.pdf)Philippe Ombredanne; IEEE Computer · Accessed 5 November 2026
4.  [AI-Generated Code: How Far Should Open Source Scanning Go?](https://haksungjang.github.io/en/blog/2026/06/08/ai-generated-code-how-far-should-open-source-scanning-go/)Haksung Jang · Accessed 5 November 2026

Produced with AI-assisted research and writing. Examples and recommendations are our editorial synthesis unless attributed. This article does not claim independent product testing or human expert review. [Read our editorial policy.](https://skillsforbusiness.ai/blog/editorial/)

## Keep reading

[AI-written CSV imports: catch column collisions before mapping rows](https://skillsforbusiness.ai/blog/ai-written-csv-imports-header-collisions/)[AI-built A/B tests: trace assignment before trusting uplift](https://skillsforbusiness.ai/blog/ai-built-ab-tests-assignment-evidence/)