[oscarvalenzuelab]

The bug

licenses.py promises that a name identifying a licence family but not a licence is never guessed at — "BSD" could be any of four, so the honest answer is that it cannot be resolved.

That promise was being kept by accident. NEVER_RESOLVE held two entries. "BSD", "Apache", "LGPL", "Public Domain" and the rest were unresolved only because ospac did not happen to carry them.

ospac is now filling in folk spellings — at our own request, in SemClone/ospac#88 and #89. A release adding bsd -> BSD-3-Clause would have made normalize("BSD") answer with a confident wrong identifier, silently. The test guarding it would have failed after the behaviour changed rather than instead of it.

A promise kept by someone else's omission is not kept.

The fix

Two parts.

The refusal is ours. The family names are on the denylist, checked before any lookup, so no upstream data reaches them. Only families whose SPDX identifiers differ by version: "MIT License", "ISC License" and "Zlib License" name one licence each and still resolve, and a version makes any family specific again.

Precedence is decided in one place. An adopter overlay still overrides a refusal — they are describing their corpus, not guessing. That was first implemented by subtracting their names from the denylist, which put the override after the SPDX parser and split it across two key spaces. Three bugs came out of that in a single review round:

overlay: gpl -> GPL-2.0-only
  normalize("GPL")  ->  GPL-1.0-or-later     the parser's deprecated mapping won

overlay: "apache software license" -> LicenseRef-Corp
  Apache Software License        ->  LicenseRef-Corp
  The Apache Software License    ->  None      same name, two answers

The adopter's own tables are consulted first now, before anything else looks at the string — their never_resolve, then their aliases, both matched in either spelling. No subtraction, no lifting, nothing to drift.

One rule, where there were two

Ambiguity used to beat an adopter's alias while the denylist did not. There is one rule now: an explicit statement by the adopter beats every refusal this tool would make. Their never_resolve still beats their own alias, being the more specific of the two.

Two tests written earlier today asserted the old split. They were changed rather than the code, and their names say so.

Four rounds, and what they cost

Review found a new instance each round — the abbreviations, then <family> License, then the written-out names, then the precedence bugs. Each fix closed the example and left the class, which is what enumeration does.

The list stopped growing at round three. A test now generates the shapes from the families rather than trusting the list: every family whose SPDX ids differ only by version, each spelling checked bare, title-cased, upper-cased and article-prefixed, plus the inverse — a version must make it resolve again. The list and the test have to agree, so the next gap fails a test instead of shipping.

Also here

A test asserted which lookup path resolved a real licence, which is ospac's data to decide. ospac 1.7.0 moved one spelling between paths and main went red on a release nobody here made. It builds its own alias now and asserts the mechanism rather than upstream's contents.

Verification

1092 tests pass; ruff and mypy clean
65,870 findings across every profile and every corpus document: 0 changed

Nothing that named a licence stops resolving — none of the refused names ever did.