build: verify third-party attribution for every embed and in NOTICE #720

New issue

Open

opened 2026-10-05 14:55:58 +00:00 by hexajon · 0 comments

hexajon commented

2026-10-05 14:55:58 +00:00

Owner

What happens

scripts/gen-third-party-licenses.sh --check runs in the gate (scripts/gate.sh:244). It regenerates THIRD-PARTY-LICENSES.md from the Go module set and diffs it, and it fails when a tracked LICENSE/COPYING/NOTICE file sits in a directory the VENDORED list does not declare (gen-third-party-licenses.sh:98-120, 274-278). That catches the case that shipped undeclared in v0.19.0: the vendored MADR templates, now declared at THIRD-PARTY-LICENSES.md:13-19.

Two gaps remain.

The vendored-content signal is a license file in the tree. A //go:embed that pulls in third-party content with no license file of its own would ship undeclared, and the gate stays green. There are four embeds today: the three MADR templates (internal/service/adr/madr/embed.go:15,21,28) and the first-party release public key (internal/cmd/update/update.go:37).
Nothing checks the root NOTICE. It is bundled into the release archive (.goreleaser.yaml:64), but its content is never verified. It carries only the project's own grant and trademark notice (NOTICE:1-45); it lists no vendored attributions. The MADR templates are used under CC0-1.0, which needs none, so there is no gap today - but a future MIT or BSD vendored file would need its attribution where recipients see it.

What I want

The attribution check reads every //go:embed directive and requires each target to be either a first-party path on an allow list or a directory declared in VENDORED. A third-party embed then fails the gate whatever license files it carries.
gen-third-party-licenses.sh generates and verifies a vendored-attribution section in the root NOTICE, the same generate-and-check pattern it already uses for THIRD-PARTY-LICENSES.md.

Acceptance criteria

A //go:embed of a path that is neither allow-listed nor declared in VENDORED fails the gate, and names the path.
The gate fails when the generated NOTICE attribution section is stale, and regenerates it on request.
The existing embeds and the current NOTICE / THIRD-PARTY-LICENSES.md pass unchanged after the one-time regeneration.

## What happens `scripts/gen-third-party-licenses.sh --check` runs in the gate (`scripts/gate.sh:244`). It regenerates `THIRD-PARTY-LICENSES.md` from the Go module set and diffs it, and it fails when a tracked `LICENSE`/`COPYING`/`NOTICE` file sits in a directory the `VENDORED` list does not declare (`gen-third-party-licenses.sh:98-120, 274-278`). That catches the case that shipped undeclared in v0.19.0: the vendored MADR templates, now declared at `THIRD-PARTY-LICENSES.md:13-19`. Two gaps remain. 1. The vendored-content signal is a license file in the tree. A `//go:embed` that pulls in third-party content with no license file of its own would ship undeclared, and the gate stays green. There are four embeds today: the three MADR templates (`internal/service/adr/madr/embed.go:15,21,28`) and the first-party release public key (`internal/cmd/update/update.go:37`). 2. Nothing checks the root `NOTICE`. It is bundled into the release archive (`.goreleaser.yaml:64`), but its content is never verified. It carries only the project's own grant and trademark notice (`NOTICE:1-45`); it lists no vendored attributions. The MADR templates are used under CC0-1.0, which needs none, so there is no gap today - but a future MIT or BSD vendored file would need its attribution where recipients see it. ## What I want 1. The attribution check reads every `//go:embed` directive and requires each target to be either a first-party path on an allow list or a directory declared in `VENDORED`. A third-party embed then fails the gate whatever license files it carries. 2. `gen-third-party-licenses.sh` generates and verifies a vendored-attribution section in the root `NOTICE`, the same generate-and-check pattern it already uses for `THIRD-PARTY-LICENSES.md`. ## Acceptance criteria - A `//go:embed` of a path that is neither allow-listed nor declared in `VENDORED` fails the gate, and names the path. - The gate fails when the generated `NOTICE` attribution section is stale, and regenerates it on request. - The existing embeds and the current `NOTICE` / `THIRD-PARTY-LICENSES.md` pass unchanged after the one-time regeneration.

hexajon referenced this issue

2026-10-05 15:05:31 +00:00

docs(adr): record the release-notes and attribution gates as 0050 and 0051 #722

hexajon referenced this issue from a commit

2026-10-05 15:05:32 +00:00

docs(adr): add proposed 0050 and 0051 for release-notes and attribution gates

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

sixfold-space/madtea#720

No description provided.

Rows
Columns