Skip to content

Validate generated license metadata before release #507

Description

@purefunctor

Follow-up opportunity

Nonblocking release-tooling follow-up from #505, verified at 429c883a. The CLI split correctly changes the license-bundle root to iris-cli, and the final commit fixes the configuration crate declaration. Generated metadata can nevertheless retain unresolved entries without an explicit validation step.

This is a metadata completeness observation, not a conclusion that any distributed binary violates a license. Most of the placeholders predate this PR; platform applicability and notices already supplied elsewhere need checking.

Evidence

  • just licenses runs cargo bundle-licenses --prefer MIT against compiler-bin/iris-cli and writes THIRDPARTY.toml, without validating unresolved output.
  • Parsing current THIRDPARTY.toml finds 51 package records with at least one license text equal to NOT FOUND (52 on the PR base). Examples include local crates with No license specified and external crates with a declared SPDX expression but no extracted text.
  • The head also contains winapi-i686-pc-windows-gnu and winapi-x86_64-pc-windows-gnu 0.4.0 records declaring MIT with text = "NOT FOUND"; neither record existed in the base bundle. These were added with the dependency changes for cache-directory logging.
  • Both .github/workflows/release.yml and canary.yml include the checked-in bundle in archives. The configuration-license correction demonstrates why declaring and regenerating metadata needs an explicit completeness check.

Why it matters

A large generated diff is difficult to audit manually. Successful generation is not evidence that license text was found, so dependency updates can silently introduce additional unresolved metadata into release artifacts.

Bounded completion criteria

  • Add a read-only validation command over the generated TOML that reports package/version and unresolved license declaration/text.
  • Classify existing placeholders against the shipped targets and authoritative package notices; resolve the newly added winapi records or document why another included notice covers them.
  • Gate new unresolved records in release preparation/CI. If inherited entries need temporary exceptions, keep a reviewed package/version-specific baseline with reasons rather than silently accepting every placeholder.
  • Keep generation reproducible; fix manifest/source metadata or the generator inputs rather than editing generated license text by hand. Test the validator with complete, unresolved, and explicitly acknowledged records.

Duplicate check: searched all open and closed issues for license and THIRDPARTY; no matching issue found.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    toolingChanges related to tooling

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions