Thanks PJ, Justin. I implemented the changes in apache/iggy repository according to your guidance:
- DEPENDENCIES.md dropped from source repo + CI check; eight NOTICE references removed. - Per-artifact license manifest generated at build time via cargo-about (Rust) and license-checker-rseidelsohn (Node), scoped to each bundled binary's actual deps (no workspace over-listing). Bundled at /usr/share/doc/<image>/ in Docker images and *.dist-info/licenses/ in the PyPI wheel. - iggy-server statically embeds the web UI, so apache/iggy enumerates web npm deps in addition to its Rust crates. - Pre-merge CI validates every artifact's deps against the ASF accept list (about.toml); the same gate re-runs at release time. PR link: https://github.com/apache/iggy/pull/3222 Should be merged within couple of days, after review from other committers. Very good change, now we will be able to use GitHub dependabot again. Hubert Gruszecki Apache Iggy (Incubating) PPMC On 2026/05/06 11:27:53 Hubert Gruszecki wrote: > Hello, > > We would like to confirm our reading of ASF release/distribution policy > regarding third-party dependency listings. > > Today we ship: > > 1. Source release (the official Apache release): a signed tarball > containing source code and lockfiles (Cargo.toml/Cargo.lock, > pyproject.toml, package.json, gradle.properties, .csproj, go.mod). > Third-party dependencies are NOT bundled in the tarball; they are fetched > from public registries at build time. > > 2. Multiple convenience distributions, all derived from the same source > release: > - Docker Hub: apache/iggy, apache/iggy-mcp, apache/iggy-bench-dashboard, > apache/iggy-connect, apache/iggy-web-ui (compiled Rust binaries, statically > linked). > - crates.io: iggy, iggy-cli, iggy_binary_protocol, iggy_common (Rust > source crates). > - PyPI: Python SDK (PyO3/maturin wheels that bundle compiled Rust code). > - Maven Central: Java SDK. > - npm: Node SDK. > - NuGet: C# SDK. > - Go module: foreign/go (tag only, no registry). > > Among these, the Docker images and the PyPI wheels physically bundle > compiled third-party code; the crates.io packages and language-source SDKs > ship source or managed assemblies with declared (not bundled) dependencies. > > We currently maintain a self-imposed DEPENDENCIES.md at the repo root, > generated from "cargo license", listing all transitive crate dependencies > and their license metadata. Our NOTICE file points to it: > > "For a complete list of dependencies, including their licenses and > repository links, please refer to the DEPENDENCIES file." > > A CI check fails the build if DEPENDENCIES.md drifts from Cargo.lock. This > creates real friction on dependency-bump PRs, mainly because GitHub > dependabot doesn't have ability to run repository scripts or pre-commit > hooks after bumping a lockfile. It updates Cargo.toml / Cargo.lock and > stops there, so DEPENDENCIES.md goes stale and the check fails on every > dependabot PR until a committer regenerates the file locally and > force-pushes to the PR branch before merging. > > Our understanding: > > From the Apache Release Policy, the Licensing How-To, the Third-Party > License Policy, and the Incubator Distribution Guidelines: > > https://www.apache.org/legal/release-policy.html > https://infra.apache.org/licensing-howto.html > https://www.apache.org/legal/resolved.html > https://incubator.apache.org/guides/distribution.html > > Two policy statements seem decisive: > > "The LICENSE and NOTICE files must exactly represent the contents of the > distribution they reside in. Only components and resources that are > actually included in a distribution have any bearing on the content of > that distribution's NOTICE and LICENSE." > -- infra.apache.org/licensing-howto.html > > "LICENSE and NOTICE MUST NOT provide information about materials which > are not bundled in the package, such as separately downloaded > dependencies." > -- apache.org/legal/release-policy.html > > "Do not modify LICENSE or NOTICE for non-bundled dependencies." > -- infra.apache.org/licensing-howto.html > > For the source tarball, our reading is: > > - Crate dependencies are not bundled (only Cargo.toml/Cargo.lock are). > - Therefore LICENSE and NOTICE should list only bundled materials, not > crates.io dependencies. > - A separate DEPENDENCIES.md is not required by ASF release policy or > Incubator policy. > > For the convenience binary distributions, our reading is: > > - Each artifact's LICENSE/NOTICE must reflect the artifact's own bundled > contents. A Docker image or a PyPI wheel that statically links Rust > crates must include those crates' licenses inside the image/wheel; a > crates.io package or a managed-assembly NuGet/npm package that does > not bundle third-party code does not. > - Convenience artifacts are not the official ASF release; the source > tarball is. Per the incubator distribution guide, the Docker Hub > overview and the Dockerfile must each include the incubator > disclaimer, the Dockerfile must include an ASF header, release > candidates / nightlys / snapshots must be clearly tagged, and the > "latest" tag must not point to an artifact containing unapproved > code. > - A repo-root DEPENDENCIES file is convenient as the SOURCE for > generating per-artifact license bundles, but does not satisfy the > per-artifact requirement on its own. > > I checked four Apache Rust projects: > > - apache/datafusion (TLP): no DEPENDENCIES file. LICENSE.txt + NOTICE.txt > only. > > - apache/arrow-rs (Rust implementation under Apache Arrow TLP): no > DEPENDENCIES file. LICENSE.txt + NOTICE.txt only. > > - apache/iceberg-rust (Rust implementation under Apache Iceberg TLP): no > DEPENDENCIES file. LICENSE + NOTICE only. > > - apache/opendal (TLP, graduated 2024-01-18): root DEPENDENCIES.md plus > per-package files. Multi-language bindings; binary distributions. > > This suggests projects without bundled redistribution artifacts (the three > Rust libraries above) tend to omit a dependencies file, while projects with > multi-language bindings or container-image distributions (opendal) tend to > maintain one. > > Finally, questions: > > 1. For a pure-source Apache release where third-party dependencies are > fetched at build time from a public registry (crates.io) and are not > bundled in the tarball, is a separate DEPENDENCIES file (or equivalent > enumeration) required by ASF policy or by Incubator policy? > > 2. For convenience binary distributions that bundle compiled third-party > code (Docker images at apache/<project>, PyPI wheels with statically-linked > Rust, etc.), is enumerating those third-party licenses required only inside > the artifact itself (e.g. /usr/share/doc/iggy/LICENSE inside an image, > *.dist-info/licenses inside a wheel), or also somewhere visible in the > source repo? > > 3. If DEPENDENCIES.md is not strictly required, are there best-practice or > IP-clearance reasons a podling should still maintain one (e.g. to simplify > graduation review)? > > 4. Is our current NOTICE text -- "please refer to the DEPENDENCIES file" -- > acceptable, or should it be removed if DEPENDENCIES.md is dropped, since > NOTICE should only describe bundled content? > > If the answer to (1) is "not required," we plan to: > > - Drop DEPENDENCIES.md from the source repo and the corresponding CI > check. > - Remove the DEPENDENCIES reference from NOTICE. > - For each convenience artifact that bundles third-party code (Docker > images, PyPI wheels), generate and bundle a license-list inside the > artifact at release time, derived from the lockfile. > > Thank you for the guidance. > > Hubert Gruszecki > Apache Iggy (Incubating) PPMC > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
