Verify AI-written open-source license summaries against exact versions, license files, notices, SPDX expressions, and the artifact your team actually ships.

A Fluent License Summary Is Not a Permission Decision

An AI system can turn a package name and a short license identifier into a confident paragraph in seconds. That paragraph may still describe a different release, overlook a notice bundled beside the license, flatten a compound SPDX expression, treat an exception as a separate license, or assume that metadata tells the whole story. The prose can sound legally settled even when the reviewer has not opened the artifact.

Open-source review is not a vocabulary exercise. The practical question is which materials and terms apply to the exact code, documentation, data, fonts, images, or other assets a team will actually use, modify, host, bundle, or distribute. A package page may be useful discovery evidence. It is not a substitute for the files attached to the resolved version, the dependency graph, the release artifact, or qualified legal judgment.

This article is a non-legal verification workflow for AI-assisted writing. It does not interpret any particular license, decide that a use is permitted, establish compliance, or replace counsel. Copyright, contract, patent, trademark, export, privacy, procurement, and sector-specific questions can require separate analysis. AI may organize evidence and draft neutral descriptions. It must not approve a license, invent an obligation, waive a conflict, or authorize release.

1. Freeze the Component, Version, Artifact, and Use

Begin with a review card, not a prompt. Record the component’s canonical name, package ecosystem and namespace, resolved version, upstream repository, exact tag or commit, package digest when available, download source, and the application or service that consumes it. Name every output under review: source archive, compiled binary, mobile package, container image, installer, browser bundle, command-line tool, documentation site, dataset, font bundle, or other deliverable.

Then record the proposed use without translating it into a legal conclusion. Is the material unchanged or modified? Is it copied into the product, linked, vendored, generated into output, loaded at runtime, used only during a build, exposed through a network service, included in documentation, or distributed as a separate file? Which customers, regions, channels, and release versions are in scope? Mark unknown fields VERIFY. Similar package names, a floating version range, or “latest” are not reviewable identities.

Keep component version separate from package-manager version, repository branch, container tag, and product release. A lockfile can resolve a different version than a manifest range suggests. A rebuilt archive can differ from an upstream tag. A container label can point at mutable content. Freeze the identifiers and hashes that allow another reviewer to obtain the same inputs.

2. Assemble the Evidence Packet From the Resolved Materials

Collect the files that travel with the exact resolved component and with the upstream release. Depending on the project, the packet may include LICENSE, LICENCE, COPYING, NOTICE, copyright files, exception or addendum files, file headers, package metadata, manifests, lockfiles, an SBOM, release notes, the signed or tagged upstream source, vendored directories, generated-file headers, and the source archive used by the build. Preserve directory paths because a notice beside one subcomponent may not describe every file in the repository.

Compare those materials rather than choosing the most convenient label. If package metadata says one thing, the root license file says another, and a subdirectory contains additional terms, record the conflict and put the summary on HOLD. Do not ask a model which source “probably wins.” The owner must identify the exact provenance and a qualified reviewer must decide how the materials relate.

An SBOM and a lockfile are valuable inventory evidence, but neither is a complete license decision. They can omit generated assets, copied snippets, fonts, documentation, nested archives, optional packages, platform-specific dependencies, or manually vendored code. Treat the packet as a reproducible collection with capture date, source URL or repository location, hashes where practical, collector, and access restrictions.

3. Minimize Private Material Before AI Sees It

License review does not create permission to upload proprietary source code, private repository history, customer data, unreleased product plans, credentials, vulnerability details, or confidential agreements to a general-purpose model. Follow the organization’s approved AI and data-handling rules. Give the drafting system the minimum verified fields and excerpts needed for wording, using an approved environment for any sensitive material.

A model-ready packet can often contain component identifiers, a bounded use description, exact SPDX strings, public license-file locations, reviewer-approved facts, and a ledger stripped of secrets. Keep private source, commercial addenda, security findings, and counsel communications in the controlled evidence system. Replace internal product names with stable placeholders when they are irrelevant to the summary.

The voluntary NIST Generative AI Profile discusses risks including confabulation and data privacy. Those risks matter here: a model may confidently fill a missing license field or retain more private context than the writing task needs. Minimization limits exposure. It does not validate the resulting legal or factual claims.

4. Preserve the SPDX Expression Exactly

SPDX license expressions are structured identifiers, not decorative shorthand. Copy the expression from the reviewed evidence exactly, including capitalization, parentheses, and operators. Store the original value before any approved normalization. The SPDX 3.0.1 license-expression annex defines how identifiers and compound expressions are represented.

  • AND: preserve a conjunctive expression; do not rewrite it as a menu of alternatives.
  • OR: preserve the choice structure and its parentheses; do not select a branch because the model calls it “standard.”
  • WITH: keep the listed exception or custom AdditionRef attached to the simple license expression it qualifies; do not list the addition as a standalone license.
  • +: preserve the defined later-version marker when it appears; do not drop, expand, or silently modernize it.
  • LicenseRef-...: keep the custom reference and its controlled definition; do not replace it with the nearest familiar license name.

Operator precedence and grouping can change meaning, so retain parentheses and review the parsed structure rather than comparing strings casually. A deprecated identifier, a project-specific LicenseRef or AdditionRef, or a document-scoped reference requires investigation, not autocomplete. If the organization maps an older identifier to a current one, keep the observed value, mapped value, rule, tool version, reviewer, and reason so the transformation remains auditable.

The canonical SPDX License List publishes identifiers, license texts, exceptions, and related metadata for standardized reference. Matching an SPDX identifier supports consistent identification. It does not prove which terms apply to a file, that the upstream declaration is accurate, that a package is OSI-approved, or that a proposed use is permitted.

5. Separate Identification, OSI Approval, and Applicable Terms

Ask three different questions and keep three different evidence fields. First: what license identifier or expression is present in the exact materials? Second: does a license appear on the relevant approval list, based on the current authoritative source? Third: which terms and other rights affect this particular artifact and use? An answer to one question does not settle the others.

The Open Source Definition states the criteria used for open-source software, the Open Source Initiative FAQ provides context about open-source licenses, and the current OSI Approved Licenses catalog is the direct record to check for an approval statement. Do not infer approval from the word “open,” a repository badge, an SPDX identifier, or a model’s recollection.

Likewise, OSI approval does not identify the license attached to the reviewed file and does not resolve notices, exceptions, multiple licenses, commercial terms, or the proposed use. Phrase the draft narrowly: report the observed identifier, evidence location, and verified approval status only when those fields were checked. Route interpretation and permission questions to the named legal reviewer.

6. Build a Claim-and-Evidence Ledger

Create one ledger row for each component, subcomponent, and consequential sentence. Useful columns include component and version, artifact and path, source repository and tag, digest, observed license expression, exact evidence file and line or section, related notice or addendum, package metadata value, SBOM value, upstream value, proposed-use context, conflict notes, reviewer, evidence date, and state: VERIFIED, VERIFY, CONFLICT, or REMOVE.

Keep observations separate from conclusions. “Manifest contains expression X” is an observation. “Use is allowed” is a legal conclusion and must not appear unless an authorized reviewer has supplied approved wording for the exact scope. “No notice found in this archive” describes a bounded search; it does not prove that no notice or obligation exists elsewhere.

Link to evidence instead of pasting long license text into model prompts, tickets, or published summaries. Preserve the full reviewed files in the controlled record. The model output is never evidence, and repetition across package indexes is not independent confirmation. When two sources disagree, retain both and name the person responsible for resolution.

7. Identify Possible Obligation Areas Without Inventing Them

A reviewer may need to locate language about attribution, notices, source availability, redistribution, modifications, installation information, network use, documentation, advertising, patent rights, trademarks, warranties, liability, or other subjects. That list is a search plan, not a statement that any specific license contains any specific requirement. Record the exact text location and ask the qualified reviewer what it means for the frozen use.

Never produce a generic “permissive versus copyleft” checklist and apply it to a component by category alone. Do not say that a notice file is optional, that a source offer is required, that linking creates a particular result, or that hosting avoids distribution without reviewing the actual terms and facts. If the evidence does not support approved wording, the accurate summary is legal review required, not a confident guess.

The U.S. Copyright Office’s Copyright Basics circular is useful background on copyright and ownership in the United States. It does not interpret a project’s license or decide a software-release question. Other jurisdictions and rights may differ. Use primary legal text and qualified advice appropriate to the organization rather than treating a general explainer as a license ruling.

8. Separate Code, Documentation, Data, Fonts, and Other Rights

A repository can contain materials governed by different terms. Inventory source code, compiled code, examples, documentation, generated output, datasets, model files, images, icons, audio, and fonts separately. Preserve file-level headers, subdirectory notices, and third-party attribution records. A root-level identifier should not overwrite more specific evidence without reviewed justification.

Keep copyright-license analysis separate from patent and trademark questions. A software license identifier does not by itself answer whether a patent grant, patent condition, brand name, logo, product endorsement, or certification mark can be used as proposed. Commercial agreements, marketplace terms, contributor agreements, support contracts, and dual-licensing offers may also add facts that do not belong in a public AI prompt.

The public summary should say only what the evidence owner and legal reviewer approve. It can identify that separate asset classes and rights were checked, but it should not collapse them into “fully open source,” “free for any use,” “no restrictions,” or “compliant.” Those phrases are broader than an inventory observation and can conceal important boundaries.

9. Reconcile the Dependency Graph With the Built Artifact

Review the resolved graph, not only the top-level manifest. Account for transitive, optional, peer, platform-specific, feature-gated, build, test, and development dependencies. Determine which components are downloaded, compiled, bundled, copied, transformed, or omitted in the release pipeline. Generated clients, vendored code, minified browser bundles, native libraries, base images, package-manager caches, and installer payloads deserve explicit attention.

Labels such as “dev dependency” or “optional” describe package configuration, not necessarily the final artifact. Verify the actual build. Record tool versions and flags used to produce the SBOM or inventory, plus known blind spots. If two scanners disagree, investigate the component path and evidence rather than averaging their labels.

After the build, unpack or inspect the exact release candidate. Compare its packages, files, metadata, license material, notices, and attribution surfaces with the approved ledger. Check the container layers, static assets, documentation bundle, installer, and downloadable source package that customers will receive. The repository can be correct while the packaging step drops a reviewed notice or includes an unreviewed asset.

10. Give AI a Bounded Documentation Task

Once the evidence and approved conclusions exist, use a prompt that makes uncertainty visible:

Draft a neutral component summary only from VERIFIED ledger rows. Preserve exact component names, versions, artifact paths, SPDX identifiers, parentheses, AND, OR, WITH, +, LicenseRef and AdditionRef values, evidence locations, and approved scope wording. Keep identification, OSI approval, and applicable-term conclusions separate. Do not infer permission, compliance, obligations, license compatibility, patent rights, trademark rights, or the meaning of missing files. Mark every gap [VERIFY] and list conflicts after the draft.

Compare the output field by field with the ledger. Search for lost operators, expanded acronyms, changed versions, altered package scopes, simplified LicenseRef values, and claims such as “safe,” “compatible,” or “no restrictions.” A copy edit that removes one parenthesis can materially change the recorded expression. Treat exact identifiers as protected data.

Keep a controlled review record containing the release card, source packet manifest, hashes, model-ready input, prompt, tool and version when policy requires, generated draft, human edits, unresolved questions, approval, and final published copy. Retain evidence according to policy without duplicating private source or legal advice into low-control systems.

11. Inspect the Final Notice Surface

Review what a recipient or user will actually see. Depending on the approved plan, that may include files in an archive, an installer view, an in-product notices page, command-line output, documentation, an about screen, a source offer location, or accompanying written materials. Do not invent which surface is required. Verify that the surface chosen by the legal and release owners is present, legible, complete, and tied to the correct product version.

Open the final files and follow every reference. Confirm that links resolve to controlled destinations, package names and versions match the artifact, line wrapping has not damaged identifiers, and generated HTML has not interpreted operators as markup. Check accessibility and searchability of the notice surface. A notice hidden in a missing layer, broken archive, or inaccessible interface is not the artifact the reviewer approved.

Run the inventory again on the release candidate and compare it with the approved snapshot. New, removed, or changed components go back through triage. Do not copy yesterday’s summary onto today’s build because the product version changed only by a patch number.

12. Put Named Owners Behind RELEASE or HOLD

Assign each decision to a role. Engineering owns the dependency path, build configuration, modifications, and exact shipped bytes. Security or software-supply-chain staff own provenance controls, inventory tooling, and related risk evidence. Documentation owns accurate, bounded wording and the final presentation. Legal owns legal interpretation and approved conclusions. The release owner confirms that all required decisions apply to the named artifact and destination.

The release record should state RELEASE or HOLD, identify the immutable artifact or digest, list reviewers, link to the sanitized evidence ledger, and record conditions or exclusions. HOLD when the version is unresolved, source materials conflict, an SPDX expression was changed, a custom reference lacks its definition, asset classes are mixed together, applicable terms are unclear, the built artifact differs from the SBOM, or the approved notice surface is missing.

Recheck after any component version, package source, lockfile, upstream tag, patch, build flag, platform, feature, base image, distribution channel, product use, commercial term, or planned audience changes. Give engineers a route to report unexpected files and give users a correction route for published notices. When an error is found, pause the affected release when appropriate, correct the canonical evidence and derived summaries, and preserve the before-and-after record.

Ten Questions Before an AI License Summary Ships

  • Does the review card identify the exact component, resolved version, tag or commit, digest, artifact, and proposed use?
  • Were LICENSE, COPYING, NOTICE, addenda, file headers, metadata, lockfile, SBOM, upstream tag, and vendored materials checked?
  • Were private code, agreements, credentials, customer data, and security details kept out of unapproved AI systems?
  • Does the summary preserve every SPDX identifier, parenthesis, AND, OR, WITH, +, LicenseRef, and AdditionRef value?
  • Are SPDX identification, OSI approval, and which terms actually apply presented as separate questions?
  • Does every factual sentence map to a dated evidence-ledger row rather than to model output?
  • Were code, documentation, data, fonts, other media, patent, trademark, and commercial terms kept distinct?
  • Was the resolved dependency graph reconciled with the exact binary, archive, container, installer, or site being released?
  • Did qualified legal, engineering, security or supply-chain, documentation, and release owners complete their assigned review?
  • Does the record say RELEASE for this exact artifact and destination, with a recheck trigger for version, package, or use changes?

If any answer is no, polished prose is not a reason to ship. Keep the summary on HOLD, resolve the evidence or ownership gap, and inspect the release candidate again. AI can make a reviewed record easier to read. It cannot decide what permission exists, determine compliance, or turn a package label into legal analysis.

Scope Notes and Primary Sources

Review Your Draft in One Workspace

Check AI-likelihood signals, revise structure and tone, and keep license evidence, legal interpretation, and release decisions with accountable humans.

Open AI Humanizer