You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@iggy.apache.org by Hubert Gruszecki <hg...@apache.org> on 2026/05/06 11:27:53 UTC
Non-bundled deps in source release: is DEPENDENCIES file required?
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
Re: Non-bundled deps in source release: is DEPENDENCIES file required?
Posted by PJ Fanning <fa...@apache.org>.
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 <hg...@apache.org> 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
Re: Non-bundled deps in source release: is DEPENDENCIES file required?
Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,
Answer from the Policy MCP with minor edits:
I now have everything needed to give a thorough, policy-grounded answer. Let me respond to each of Hubert's four questions.
Q1: Is a separate DEPENDENCIES file required for a pure-source release?
No. The Release Policy is explicit: "LICENSE and NOTICE MUST NOT provide information about materials which are not bundled in the package, such as separately downloaded dependencies." This cuts both ways. Not only are you not required to enumerate non-bundled crate dependencies in LICENSE/NOTICE, but you are also actively prohibited from doing so in those specific files. A separate DEPENDENCIES.md is not required by either the Release Policy or the Incubator Distribution Guidelines. Your reading is correct, and the datafusion/arrow-rs/iceberg-rust precedents are consistent with that reading.
Q2: Where must third-party licenses appear for convenience binary distributions?
Inside the artifact itself. The policy is per-artifact: "Each package MUST provide a LICENSE file and a NOTICE file which account for the package's exact content." For Docker images and PyPI wheels that statically link compiled Rust crates, those crates' licenses must be present within the image/wheel at the standard location (e.g., /usr/share/doc/iggy/ or *.dist-info/licenses/). There is no policy requirement that license enumerations for binary artifacts also appear in the source repo. The source repo DEPENDENCIES.md can serve as a convenient source for generating per-artifact bundles, but the repo-root file does not satisfy the per-artifact requirement on its own.
One Incubator-specific addition: the Incubator Distribution Guide requires that Docker Hub images carry the DISCLAIMER, that the Dockerfile include an ASF header, and that release-candidate and nightly tags be clearly distinguished from GA tags, with the latest tag never pointing at unapproved code.
Q3: If DEPENDENCIES.md is not required, are there IP-clearance reasons to keep it?
Practically, yes, though the reasons are about ease of graduation review rather than policy compliance. During graduation IP clearance, the IPMC typically wants evidence that the project has inventoried its dependencies and that nothing with a Category X has crept in. A machine-generated DEPENDENCIES.md regenerated at release time (even if not committed to the repo) is a strong signal that the project has that process in place. You could achieve the same effect by running cargo license as part of the release checklist and attaching the output to the release vote email rather than maintaining it in the repo. That sidesteps the friction with Dependabot while preserving the audit trail. Several Incubator mentors and reviewers will find it easier if the artifact contains or links to a structured license inventory, so dropping it from the repo but generating it into the artifact is a reasonable middle path.
Q4: Should the NOTICE reference to DEPENDENCIES.md be removed?
Yes, it should be removed. The Release Policy requires that "NOTICE files account for the package's exact content" and prohibits information about non-bundled materials. A NOTICE statement referencing a file listing non-bundled crate dependencies is precisely what the policy prohibits. If you drop DEPENDENCIES.md from the source tarball, the reference must go. Even if you keep the file in the repo for developer convenience, if it is not included in the source tarball, it has no place in the tarball's NOTICE.
Kind Regards,
Justin
Re: Non-bundled deps in source release: is DEPENDENCIES file required?
Posted by Hubert Gruszecki <hg...@apache.org>.
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: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Non-bundled deps in source release: is DEPENDENCIES file required?
Posted by PJ Fanning <fa...@apache.org>.
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 <hg...@apache.org> 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: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org