The summary at the end seems valid to me. For me, no need for a dependencies file but the convenience binaries with bundled libs and packages: the license and notice in these artifacts should have a full enumeration of the license and notice details from all the bundled libs and packages. So, the 'dependency' information is available in license/notice files for the convenience binaries.
On Wed, 6 May 2026 at 12:28, Hubert Gruszecki <[email protected]> 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]
