Missing third-party attribution bundle (NOTICE) in distributed binary

[dolph]

Summary

The released binary statically links several permissive-licensed Go modules, but the release artifact ships without the attribution notices those licenses require to be propagated in redistribution. The project itself is Apache-2.0 (LICENSE), and the dependency tree is fully permissive — there's no incompatibility — but the redistribution conditions of those dep licenses are not being satisfied today.

This is a legal-compliance angle distinct from the release-engineering items in #26 (SBOM/checksums/signing). #26 is about supply-chain integrity; this issue is about license-attribution obligations.

What is licensed how

From go.sum (direct + indirect deps that end up in the binary):

Module	License	Attribution requirement on binary redistribution
github.com/google/gopacket	BSD-3-Clause	Retain copyright + license text
github.com/google/uuid	BSD-3-Clause	Retain copyright + license text
github.com/prometheus-community/pro-bing	MIT	Retain copyright + permission notice
golang.org/x/net	BSD-3-Clause	Retain copyright + license text
golang.org/x/sys	BSD-3-Clause	Retain copyright + license text
golang.org/x/sync	BSD-3-Clause	Retain copyright + license text
golang.org/x/crypto (indirect, in graph)	BSD-3-Clause	Retain copyright + license text
golang.org/x/text (indirect, in graph)	BSD-3-Clause	Retain copyright + license text
gopkg.in/yaml.v3	MIT + Apache-2.0 (mixed)	Carry the Apache-2.0 NOTICE through
gopkg.in/check.v1	BSD-2-Clause (test-only)	Retain copyright + license text if shipped

No GPL / LGPL / AGPL — the binary is free to remain Apache-2.0.

What's missing

1. No NOTICE file in the repo. Apache-2.0 §4(d) requires propagating NOTICE content from upstream deps that ship one. gopkg.in/yaml.v3 includes an Apache-2.0 component; its NOTICE-equivalent content should be carried forward.
2. No THIRD_PARTY_LICENSES / attribution bundle alongside the release binary. BSD-3-Clause §2 and MIT both require the license text and copyright to travel with binary redistribution. Today the GitHub release only contains the bare connectivity binary.
3. No CI step that generates the attribution bundle, so even if added once it can drift as deps change.

Suggested fix

Lowest-friction option — add a release step that generates a THIRD_PARTY_LICENSES.txt and uploads it with the binary:

- name: Generate third-party license bundle
  run: |
    go install github.com/google/go-licenses@latest
    go-licenses report ./... --template <(echo '{{range .}}{{.Name}} {{.LicenseURL}} {{.LicenseName}}
{{end}}') > THIRD_PARTY_LICENSES.txt
    # or: go-licenses save ./... --save_path=third_party_licenses/
- name: Upload to release
  run: gh release upload "${TAG}" THIRD_PARTY_LICENSES.txt

Optionally also commit a static NOTICE file at the repo root containing the project's own copyright line and a pointer to the bundled attribution.

If #26 is resolved by switching to goreleaser, note that goreleaser has first-class support for emitting a license bundle as part of the release artifacts — the two issues can be closed together if that path is chosen.

Out of scope (deliberately)

• Per-file source-code copyright headers. Go convention is generally to omit these; nothing in the repo indicates a desire for them.
• SBOM / checksums / signing. Tracked separately in Release process: single arch, no checksums/signing, no container image, duplicated build config #26.
• The LICENSE file's appendix still contains the unfilled Copyright [yyyy] [name of copyright owner] template line. That's the Apache boilerplate's own self-description and not a defect, but adding a Copyright 20XX Dolph Mathews line above or below the license text would make the assertion explicit. Optional polish.

Why priority:low

No incompatibility, no GPL contamination, no immediate legal exposure for a hobby/utility binary — but the redistribution conditions of the upstream licenses are technically unmet today, so it's worth fixing before the project gets wider adoption.

Relates to #26 (release process).