Problem
registry-schema.json's license field only checks shape, not membership in the actual SPDX license list:
"pattern": "^[A-Za-z0-9][A-Za-z0-9.+-]*$"
This accepts any SPDX-looking string, including typos or made-up names (e.g. Apach-2.0), as long as the characters are alphanumeric plus ., +, -. It doesn't validate that the value is a real, known SPDX license identifier.
This isn't a security issue — the pattern already restricts to a safe character set, so unlike repository (#48) there's no injection risk. It's a data-quality gap. It's also one of the original requirements in #21: "SPDX license identifiers" was listed as a field CI should validate, and today it's only shape-validated.
Options considered
- Full SPDX list as an enum (~600+ identifiers via spdx/license-list-data): most complete, but enum bloat for a registry where every plugin today uses one of three licenses, and doesn't cover license expressions (
MIT OR Apache-2.0), which check-jsonschema can't validate without a small custom grammar.
- Curated enum of licenses actually relevant here (recommended): the licenses already in use (
Apache-2.0, GPL-2.0, GPL-3.0) plus a handful of common OSS licenses. Keeps the same trust model the rest of the registry already has — adding a new license means a reviewed PR to the schema, not silent acceptance of an unvetted string. Smaller and easier to maintain than the full list.
One wrinkle either way: GitHub's own license detector reports our current GPL entries as GPL-2.0/GPL-3.0, which are deprecated-but-valid SPDX IDs (superseded by -only/-or-later variants). Whatever list we land on should include those as-is rather than force an unrelated migration.
Suggested next step
Add a curated enum to the license property in registry-schema.json, seeded with the licenses currently in registry.yaml, and document in docs/registry-schema.md that new licenses are added via schema PR.
Refs #21, #48.
Problem
registry-schema.json'slicensefield only checks shape, not membership in the actual SPDX license list:This accepts any SPDX-looking string, including typos or made-up names (e.g.
Apach-2.0), as long as the characters are alphanumeric plus.,+,-. It doesn't validate that the value is a real, known SPDX license identifier.This isn't a security issue — the pattern already restricts to a safe character set, so unlike
repository(#48) there's no injection risk. It's a data-quality gap. It's also one of the original requirements in #21: "SPDX license identifiers" was listed as a field CI should validate, and today it's only shape-validated.Options considered
MIT OR Apache-2.0), which check-jsonschema can't validate without a small custom grammar.Apache-2.0,GPL-2.0,GPL-3.0) plus a handful of common OSS licenses. Keeps the same trust model the rest of the registry already has — adding a new license means a reviewed PR to the schema, not silent acceptance of an unvetted string. Smaller and easier to maintain than the full list.One wrinkle either way: GitHub's own license detector reports our current GPL entries as
GPL-2.0/GPL-3.0, which are deprecated-but-valid SPDX IDs (superseded by-only/-or-latervariants). Whatever list we land on should include those as-is rather than force an unrelated migration.Suggested next step
Add a curated
enumto thelicenseproperty inregistry-schema.json, seeded with the licenses currently inregistry.yaml, and document indocs/registry-schema.mdthat new licenses are added via schema PR.Refs #21, #48.