Read Declared and Concluded Licenses in an SPDX Software Package Record

Substantively revised October 21, 2026. Author interpretation, documented cases and hypothetical examples are distinguished below.

A software package can arrive with an impressive inventory and still leave the receiving team unsure what to ask next. One entry describes what the package authors declared. Another lists observations from its files. A third records a conclusion. The receiver copies the most familiar license name into an approval form, and the disagreement disappears without being investigated.

The receiving team has not necessarily discovered a licensing violation. It has discovered evidence that needs interpretation. That distinction changes the next conversation. Instead of asking the supplier to make every field match, the receiver can ask what accounts for the difference and whether the explanation concerns the actual delivered package. A machine-readable document is most useful when its distinctions survive human review.

Direct answer

Match the SPDX record to the delivered package and the specification version it uses. Read the license fields as different categories of information, examine any explanatory comments, and preserve unresolved values. Ask the responsible maintainer or reviewer to address a material discrepancy before treating it as an approval. A license badge or successful software build does not perform that review.

In SPDX 2.3.1, the declared field concerns the package authors’ declaration; information from files records detected licenses; the concluded field records the document creator’s analysis. Their agreement is not a substitute for examining the basis of the decision, and their disagreement is a question to investigate rather than an automatic finding against the package. [S2]

This article addresses interpretation and review routing, not a determination of license compatibility, copyright ownership or compliance for an actual product. The chosen SPDX version is an explicit reference for the examples, not a claim that it is the newest available version.

Key takeaways

Keep the question about the software you actually received. A general statement about a project’s licensing may concern a different release or distribution. Before debating the meaning of a discrepancy, make sure the participants are discussing the same delivered material and proposed reuse.

Do not ask a supplier to replace an uncomfortable value with a reassuring one unless the evidence supports the replacement. An honest unresolved state can help direct work. A tidy document produced by copying a convenient label can conceal the very uncertainty the review was supposed to expose.

Keep technical acceptance and reuse review distinct in the delivery decision. A package that runs can still require an explanation of its licensing evidence. A record with extensive licensing information can still concern a package that does not run. Neither team should quietly borrow the other team’s approval to close its own outstanding question.

Definitions and the people behind the fields

An SPDX document is a structured description used to exchange software information. A package record describes a particular package within that document. For the reading task here, distinguish a statement supplied by package authors, observations collected from material and a conclusion reached by the person or organization preparing the document. Those sources of information need not be interchangeable. [S2]

The supplier is the party delivering the package to your project. The upstream maintainer may be someone else. The person generating a document may have performed an analysis, operated a tool or received information from another party. Ask who can explain the relevant observation rather than assuming that whoever emailed the delivery can resolve every question alone.

The reuse reviewer is the person or process responsible for evaluating your proposed use under your organization’s requirements. That role might involve engineering, legal or open source program expertise. The method in this article helps prepare a precise question for that review. It does not authorize a junior receiver to invent a licensing conclusion because the project needs an answer quickly.

Root cause: a summary becomes a verdict

Many delivery processes ask a single question: what is the license? That question is understandable when choosing among software options, but it can be too compressed for receiving a particular package. Different pieces of information arrive, and the process has room for only one answer. The receiver makes them look equivalent because the form offers no place to preserve their different roles.

The temptation is strongest when a familiar label already appears on a repository page. The label provides an anchor for the conversation. A later observation that seems inconsistent with it can feel like a clerical error. Instead of asking how the label was produced or what it describes, the team treats the rest of the evidence as something to normalize around that first impression.

A more useful starting point is that a discrepancy has an explanation to seek. It might reflect a distinction in scope, a mistake in the document, material requiring further attention or something the current participants do not understand. These are possible investigative directions, not diagnoses. Keep them as questions until the appropriate evidence distinguishes them.

My proposed insight is that the value of a software inventory can increase when it exposes a well-located uncertainty. Teams often reward completion and consistency because those are easy to count. But a clearly explained unresolved question can prevent an approval from depending on an assumption nobody intended to make. Suppressing that question makes the document look better while making the decision harder to defend.

Framework: the License Disagreement Interview

The License Disagreement Interview is an author-proposed method for preparing a software receipt conversation. It is not an SPDX requirement or a legal assessment. Its components are Delivery, Difference, Explanation and Decision Owner. Use it when the licensing evidence supplied with a package cannot be reduced to a clear, supported statement about the proposed reuse.

Delivery establishes the common object of discussion. Ask the supplier to identify which distribution the document describes and compare that with the delivered material. If the package was repackaged, ask how that affects the explanation being offered. A shared project name is not enough when different participants may be looking at different distributions or revisions.

Difference states the actual discrepancy in neutral language. Instead of writing “supplier licensing wrong,” identify which observations appear difficult to reconcile. Describe the field, source and relevant material without assigning blame. A good question lets the supplier reproduce what puzzled the receiver. A vague accusation often produces reassurance instead of an explanation.

Explanation asks what supports the proposed interpretation. Request the relevant package information, analysis or maintainer clarification, rather than asking for a document with cosmetically matching labels. If the explanation says that a finding concerns only a particular component, the appropriate reviewer still needs to understand how that component relates to the proposed use. The receiving team should not make that judgment by deleting the inconvenient finding.

Decision Owner identifies who can decide what to do with the explanation. The supplier can explain its delivery without necessarily approving your product’s intended use. An engineer can identify what is included without supplying a legal conclusion. Keep the unresolved question assigned to the appropriate role so that it does not drift back to whoever happens to be holding the release checklist.

The interview ends with an explicit state: the material question has been addressed through the appropriate review, further information is needed, the software option will change, or the proposed use will be revised. It need not end with the receiver personally deciding the license. A well-routed question can be a complete operational result even while a broader project decision remains pending.

Three documented mechanisms that make the distinction concrete

First, SPDX’s license guidance uses precise identifiers and distinguishes AND from OR combinations. That precision is part of the information being exchanged; punctuation is not merely a stylistic preference. Preserve the expression when preparing a question rather than replacing it with an informal label that loses the distinction. [S1]

Second, SPDX 2.3.1 provides separate categories for package license evidence and allows unresolved information. NOASSERTION should not be silently converted into NONE or a preferred license name. When a conclusion differs from a declaration, the specification calls for explanatory comments. The document can preserve a question instead of pretending it has been answered. [S2]

Third, GitHub explains that its license detection compares a repository LICENSE file with known licenses and can encounter multiple-license complexity. A repository display is therefore a useful starting point, not a complete investigation of every delivered component. The platform’s own explanation helps identify what additional evidence a receiver may need. [S3]

These are three documented mechanisms in actual standards and tooling guidance. They are not three reports of a supplier’s successful compliance review. Their practical lesson is to keep information from different sources distinguishable when humans discuss it. The interview is designed around that conversational problem rather than around producing another scanner score.

Hypothetical case study: a contractor’s reporting utility

Imagine a small company receiving a reporting utility from a contractor. The delivery contains a source archive, a runnable build and an SPDX document. The company plans an internal pilot in 12 days. Two engineers can inspect the delivery, while a separate reviewer handles licensing questions. These quantities, roles and events are hypothetical planning details, not an account of a real company or a recommended approval timetable.

One engineer confirms that the utility runs on the agreed test environment. Another notices that a package record’s licensing evidence is not explained by the contractor’s short delivery note. The project manager initially asks the contractor to send a corrected inventory by the next morning. That request assumes the inventory is the mistake before anyone has investigated the discrepancy.

Using the License Disagreement Interview, the receiving team first establishes that the document concerns the same archive as the delivered utility. The contractor realizes that its explanatory note was written for an earlier delivery. The team does not infer that this discovery resolves the entire licensing question. It simply removes one source of conversational confusion.

The receiver then states the remaining difference and asks for the relevant analysis. Suppose the contractor identifies an included component and supplies a more precise explanation of where it appears. The engineers can help describe its technical role. The designated reviewer can then evaluate the proposed use with the actual information, rather than receiving a form containing only a familiar repository label.

If the information remains insufficient, the pilot decision stays open. The company may request further evidence, change the software option or revise its proposed use through the appropriate process. There is no necessary approval ending to the example. The process is useful because it prevents “the build works” from becoming an accidental answer to a different question.

The team’s final handover note explains the distinction. It records that technical execution was demonstrated for the agreed test, identifies the licensing question routed to review and names the next responsible role. That is more useful to the next project manager than a single status saying “package checked,” because the phrase would hide which part of acceptance actually occurred.

Failure example: repairing the document instead of the uncertainty

Consider a hypothetical supplier asked to remove every unresolved value before a delivery can be accepted. An employee copies the repository’s familiar license label into the disputed entries. The receiving team’s automated check now finds a complete document, and the release checklist turns green. No new evidence has entered the review.

The failure is not that automation checked a field. It is that the project treated field completion as the desired outcome and stopped asking how the value was established. The resulting record can be harder to interpret than the earlier incomplete one, because the original uncertainty has vanished. A later reviewer may reasonably assume that someone investigated it.

Repair starts by recovering the question, not by demanding another cosmetic correction. Ask what evidence supported the replacement and whether the person making it was recording a conclusion they could explain. If the answer is only that a blank or unresolved entry was unacceptable to the receiving system, the review needs to address that process design.

Do not treat this hypothetical pattern as proof of dishonesty in a real supplier. A workflow can produce a bad information outcome through poorly chosen incentives and ambiguous requests. State the actual discrepancy, ask for its basis and involve the responsible reviewer. Public accusations and universal claims about the package do not follow from an incomplete receipt conversation.

Tradeoffs and counterargument

A reasonable objection is that small teams cannot become specialists in every software licensing system. The interview does not require that. Its purpose is to prepare a bounded question for the person who can interpret it, rather than letting an unqualified receiver make a hidden conclusion. Better routing can reduce repeated exchanges in which everyone discusses the package generally but nobody addresses the actual discrepancy.

Another objection is that an inventory with many unresolved entries may be unusable for a deadline-driven project. That can be a legitimate production concern. The project may need a different dependency or a clearer delivery before proceeding. What does not follow is that unresolved entries should be changed without evidence so that the inventory becomes acceptable to a form.

There is also a cost to reviewing immaterial differences indefinitely. A receiving team should explain why the question matters to the actual proposed use and let the responsible process assess it. Do not invent a rule that every textual difference requires the same level of escalation. A precise description of scope helps the reviewer distinguish a substantive question from a misunderstanding of how the information is represented.

The opposite mistake is to assume that sophisticated machine-readable evidence must already settle the decision. A rich document can improve communication while leaving the judgment open. Its usefulness lies partly in making the remaining question inspectable. The presence of more fields changes what you can ask; it does not transfer all responsibility for your use to the file format.

Common mistakes

The first mistake is asking for a clean report without specifying what clean means. If the real requirement is an explanation of a discrepancy, say that. Otherwise the supplier may optimize for the appearance of consistency rather than the information the reviewer needs. Your request should reward an accurate answer, including an appropriately unresolved one.

The second mistake is treating a different release’s documentation as though it automatically explains the current delivery. Establish the shared object before spending time debating the answer. This can be a simple practical check, but it should be explicit enough that a later reader does not have to guess which package was discussed.

The third mistake is assuming a technical maintainer can approve every downstream use. A maintainer may be able to clarify included material or correct a package record. That contribution can be valuable without supplying all the judgments required for your product. Preserve the role distinction when handing the answer to the responsible reviewer.

The fourth mistake is trying to settle uncertainty by counting how many sources repeat a label. Several displays may inherit information from the same original declaration. Repetition can make an assertion look independently confirmed when it has only been copied. Ask about the source of the interpretation rather than treating the number of matching screens as decisive.

The fifth mistake is losing the original concern after a corrected document arrives. Compare the explanation with the question that prompted the correction. A changed value can be appropriate, but the receiving team should understand the basis rather than assuming that any change means the review succeeded.

Action plan for a package receipt meeting

Before the meeting, select the actual delivery and identify the one discrepancy that prevents a supported reuse decision. Write a neutral question that someone with the relevant package knowledge can investigate. Avoid sending a general demand to certify all software if the immediate issue concerns a particular part of the supplied evidence.

During the meeting, establish the shared delivery, ask for the explanation and identify the role responsible for judging its relevance. Keep technical demonstrations tied to their actual purpose. A successful run can complete an execution check without closing the licensing question that brought the meeting together.

Afterward, record what was clarified, what remains open and who acts next. If the package or proposed use changes, make that change visible to the reviewer. The practical endpoint is an understandable handover of the decision, rather than a status word that nobody can later interpret.

FAQ

Does a repository license badge describe every delivered file?

Do not assume that it does. Use the badge as a lead and inspect the evidence relevant to the delivered material. GitHub’s own detection guidance describes a narrower mechanism than a complete downstream reuse review. [S3]

Should all license-related fields always match?

Do not make matching the goal before understanding what the fields represent. An apparent difference should prompt an explanation of the actual material and analysis, rather than automatic normalization around the most familiar label.

Is an unresolved entry proof that reuse is prohibited?

An unresolved entry identifies a gap in the information being asserted. Route the relevant question through the appropriate review instead of converting the gap into either an approval or a universal prohibition.

Can I replace an unresolved value with a plausible license?

Only record a supported conclusion through the appropriate process. Plausibility or a deadline does not provide the missing evidence. Changing the label without resolving the question can make the record less reliable.

Does a successful build close the licensing review?

No. Running the software demonstrates something about execution in a particular environment. It does not decide all questions about the proposed reuse. Keep those acceptance responsibilities distinguishable.

Should I ask the supplier to guarantee my entire product?

Begin with the actual discrepancy and proposed use. A broad assurance may be less informative than a precise explanation of the delivered component. Use the contractual and review process appropriate to the project for wider requirements.

Who should answer a package composition question?

Ask the person with appropriate knowledge of the delivery, which may involve the supplier or upstream maintainers. The answer can inform the reviewer without automatically transferring responsibility for your product’s decision to that person.

Is the SPDX version relevant?

Yes. Read a document using the specification context it identifies. This article uses 2.3.1 for its bounded examples; it does not establish that every other version or representation has identical requirements.

Can a scanner replace the receiving conversation?

A tool can supply observations, but the receiving team still needs to understand what question those observations address. When the issue remains material, seek a supported interpretation rather than treating the existence of a scan as approval.

What if the supplier sends a corrected inventory?

Compare the explanation with the original question. Confirm that the correction addresses the delivered material and has a basis, rather than assuming any newer document has automatically resolved the concern.

Does more licensing information always mean a worse package?

No. More detail can make previously hidden questions visible. Evaluate what the evidence establishes and what review remains, rather than penalizing a supplier merely for preserving an accurate uncertainty.

What if the project cannot wait for clarification?

Take the unresolved question to the appropriate decision owner and consider available alternatives. The deadline can influence the project choice, but it does not change the evidentiary meaning of the supplied record.

Can several matching websites independently confirm the label?

They may be repeating the same underlying information. Investigate the source relationship where it matters to the decision. Counting displays does not establish that separate analyses occurred.

Does this article determine license compatibility?

No. It prepares evidence and questions for a responsible review. A compatibility conclusion about an actual distribution requires the relevant material, proposed use and appropriate expertise rather than this general interview method.

What should the final receipt note make clear?

Explain the delivery discussed, the material question, the information received and the next decision owner. A colleague should be able to continue the work without guessing what an unexplained “licensing checked” status covered.

Recommended books

Karl Fogel’s Producing Open Source Software: How to Run a Successful Free Software Project offers context on the human side of maintaining a project and communicating with its participants. Its relevance is asking useful, answerable questions of maintainers. It is not the SPDX 2.3.1 specification or a determination about the package you received.

Software Engineering at Google, curated by Titus Winters, Tom Manshreck and Hyrum Wright, provides context on engineering practices and software maintained over time. Use it to think about why delivery information needs to remain understandable as people and releases change. It does not supply a project-specific licensing approval.

Nadia Eghbal’s Working in Public: The Making and Maintenance of Open Source Software examines the work and people sustaining open source projects. Its relevance here is treating maintainer clarification as real work rather than an unlimited free certification service. It does not resolve the legal meaning of a particular distribution or replace its actual evidence.

Further exploration

Review one recent software receipt and ask what the final approval word concealed. Did it refer to execution, completeness, an explanation from the supplier or a reuse decision by the appropriate reviewer? If these meanings have become mixed together, improve the next handover by naming the actual decision and the evidence considered.

Then examine the requests your team sends when it finds uncertainty. Do they ask for an explanation, or merely for a more reassuring report? The difference can determine whether a structured inventory helps the organization learn what it received or becomes another form that rewards premature confidence.

Primary evidence sources

• [S1] spdx-license-evidence: License IDs and expressions, lines 39-40, 85-97, 114-122
• [S2] spdx-license-evidence: 7.13-7.16, lines 713-848
• [S3] spdx-license-evidence: Choosing a license and Detecting a license, lines 38-49, 94-97

Related concepts: systems thinking, wealth structure, and the survival loop. Read the editorial policy and citation guide.