Do not flatten an SPDX license expression into a license list

Preserve the declaration before deciding use

A software archive owner receives an export listing MIT and Apache-2.0 for a component. The names look familiar, but the reviewer cannot tell whether the source declared a choice or a combination. Asking the reviewer to choose a favorable interpretation would turn an export defect into an undocumented licensing decision. Recover the declaration first.

SPDX Specification v2.3.1 uses OR for alternatives, AND for simultaneous requirements and WITH for a specified exception. Parentheses control grouping. These relationships belong to the declaration; sorting its identifiers into a list does not preserve them. This article examines that representation problem, not whether any actual component is correctly licensed.

Run a completed loss-detection fixture

The following hypothetical fixture invents four component records and a faulty exporter. No real package, repository or license grant was examined. The exporter keeps familiar identifiers but drops operators or unresolved references. Each row receives a completed decision so an owner can specify what the repaired export must retain.

E1 and E2 deliberately become the same output. Once that happens, the recipient cannot reconstruct the original relationship from the list. Replacing the comma with OR would repair E1 while changing E2. The appropriate action is to return to the preserved source, rather than guess from the exported names.

Removing parentheses can change a branch

Add hypothetical record E5: (MIT OR Apache-2.0) AND BSD-3-Clause. Compare it with MIT OR Apache-2.0 AND BSD-3-Clause. Under the selected syntax, AND takes precedence over OR. In E5, the BSD-3-Clause requirement remains attached whichever alternative is selected. Without the parentheses, MIT alone becomes one branch of the expression.

That structural difference is sufficient to reject the transformation. It does not establish that a real user may satisfy either branch, that licenses are compatible or that the declaration covers every file. The fixture checks whether the export changed what was stated.

Give the engineer explicit expected results: keep E5’s grouping; keep E3’s exception; preserve E4 even when its text is unavailable. A search index may additionally store individual identifiers for discovery, provided it keeps a link to the intact declaration. The identifier index should not become the sole record used for permission review.

Recover the text and the declaring source

The npm CLI 11 documentation supplies a practical metadata example. Its license field supports SPDX expressions and directs custom-license users to SEE LICENSE IN with a file included in the package. It marks older license objects and arrays as deprecated. The page read on 16 October 2026 identifies itself as CLI 11.21.0, Legacy; this is a pinned documentation example, not a latest-version claim.

Do not fill a missing custom-text reference with a popular identifier. In the hypothetical review, E4 remains unresolved until the owner locates the referenced terms or records that they are unavailable. A valid-looking replacement would hide the missing evidence. Keep the original field and the normalized interpretation separately, with the reason for any correction.

For E1, the illustrative internal ledger records component C-17, release 4.2, source manifest M-17, exact declaration MIT OR Apache-2.0 and capture date 16 October 2026. It records the declaring source, not verified ownership. License-text evidence is pending; export repair is required; proposed external reuse is unapproved. These are example review fields, not required SPDX property names.

Close the export defect before the use decision

The fixture’s owner holds the faulty output, requests a corrected export and assigns missing-text recovery. A subsequent comparison should confirm that operators, grouping and references survive for the selected component versions. Record the actual exporter and test result when that work occurs. The hypothetical decisions here do not claim that a production parser or package manager was tested.

A second reviewer then considers whether the declaration is accurate and whether the actual terms support the named recipient’s proposed activity. Keep that determination beside its evidence and responsible approver. A successful representation check should never silently set a permission field to approved.

Use Inventory to describe the record category and Rights review to track missing authority or text. Begin any external description with approved metadata and fictional rows. VOID’s permissioned introduction does not transfer software rights, clear third-party materials or establish receiving-program interest in this category.