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
