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
