sungwy opened a new issue, #101:
URL: https://github.com/apache/terraform-provider-iceberg/issues/101
## Problem
`LICENSE-binary` / `NOTICE-binary` / `licenses-binary/` describe the
third-party
code bundled into the convenience binaries consumed by the Terraform and
OpenTofu
registries. They are maintained by hand, and nothing verifies them against
what is
actually linked into the binaries we ship.
They have already drifted. Verifying the v0.1.0-rc2 candidate turned up four
statically linked, non-Apache-2.0 dependencies that are neither listed in
`LICENSE-binary` nor have their license text in `licenses-binary/`:
| Module | Version | License |
| --- | --- | --- |
| `github.com/hashicorp/golang-lru/v2` | v2.0.7 | MPL-2.0 |
| `golang.org/x/oauth2` | v0.36.0 | BSD-3-Clause |
| `github.com/clipperhouse/uax29/v2` | v2.7.0 | MIT |
| `github.com/twmb/avro` | v1.7.2 | MIT |
Six entries drifted the other way — listed but no longer linked:
`go-viper/mapstructure/v2`, `golang/snappy`, `hamba/avro/v2`,
`json-iterator/go`,
`rivo/uniseg`, `golang.org/x/xerrors`.
`LICENSE-binary` is byte-identical between rc1 and rc2. It was accurate at
rc1 and
went stale when `iceberg-go` moved v0.5.0 -> v0.6.0 in #49, which reshaped
the
transitive closure. All four missing modules are `// indirect` and absent
from
rc1's `go.mod` entirely, which is why a review of direct dependencies would
not
have caught them.
This matters because the ASF licensing guidance is that "LICENSE and NOTICE
must
exactly represent the contents of the distribution they reside in," and
because
MPL-2.0 and BSD-3-Clause each independently require reproducing their
license text
on redistribution.
## Why existing CI does not catch it
`dev/check-license` runs Apache RAT, which audits ASF license headers on
source
files. It has no visibility into which third-party modules get linked into a
binary, so this class of drift is invisible to it.
## Proposed check
Diff the linked module *set* against a checked-in manifest, and fail when it
moves:
```
go list -deps -f '{{if .Module}}{{.Module.Path}}{{end}}' ./... | sort -u
```
This reproduces exactly the module set embedded in the shipped binary —
verified
identical (80 modules) against `go version -m` on the released
`terraform-provider-iceberg_0.1.0_linux_amd64.zip`. No build required.
Measured cost: **0.07s warm**, 3.5s cold (cold includes downloading the whole
module tree). `go-ci.yml` already runs `go build ./...` and `go test ./...`,
so the
module cache is warm by the time this would run.
Noise: it diffs the module *set*, not versions, so ordinary version-only
Dependabot
bumps stay silent. Across the entire rc1..rc2 window (15 commits, ~13 of them
dependency bumps), only 3 commits touched `go.mod` at all and **only 1
changed the
module set**. The check would have fired once.
Storing each module's license alongside it in the manifest narrows it
further:
additions/removals that are Apache-2.0 need no `LICENSE-binary` change and
can be
reported as informational rather than failing.
## Options
1. Append to the existing `go-ci.yml` job. Catches drift on the PR that
introduces
it, when it is one module with an obvious culprit.
2. Gate it in `dev/release/release_rc.sh` before tagging. Zero CI cost, but
you meet
the accumulated drift at the worst moment.
3. Minimum viable: a bullet in `docs/releasing.md` under "Preparing for a
Release"
to regenerate `LICENSE-binary` whenever the dependency tree moved.
Worth noting for whichever route: an automated license-classification step
has a
small false-positive floor. `cloud.google.com/go` and
`github.com/apache/thrift`
both report as Apache-2.0 *plus* BSD-3-Clause, but neither links its
non-Apache
portions (thrift's are scoped to `lib/cpp`, `lib/rb`, `compiler/cpp`;
`cloud.google.com/go` links only `civil`, with zero references to its BSD-3
`third_party/pkgsite`). Those two need an allowlist entry with a written
justification, or the check will nag forever.
A check nobody maintains is worse than no check, so option 3 is a legitimate
landing spot if nobody wants to own the manifest.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
