Hi Justin, Thanks for your feedback!
> condition 1 Can you expand on what condition 1 is? I can see some numbered items on [1] but would ask for clarification. [1] https://www.apache.org/legal/generative-tooling.html > what code-scanning or tool-provided training data exists to support the remaining conditions I can foresee that SCANOSS [2] and FOSSA [3] may help in this domain. The PPMC should investigate which suitable tools can help here. That said, peer reviews can help when certain code snippets should typically be written in a certain way. And tools may generate false positives or false negatives. [2] https://github.com/scanoss [3] https://fossa.com/products/scan/ > A commit rate of roughly 100 commits over three days To me, this is more of a technical issue. If the developer asks the agent to commit on every small step for easy review and take responsibility for the final result, this is totally possible. Otherwise, the developer can keep the process locally or stay only in a PR without being in the main branch, but the final action is the same. So I'm less concerned about N commits. But if it helps, developers can keep that experimental process out of VCS history, just like you don't commit every line edit separately. > commits are made by human committers who have reviewed the change and can stand behind it Reasonable point. Then I agree that we can suggest to the developers that they keep local commits out of the final commit history. Best, tison. Justin Mclean <[email protected]> 于2026年8月11日周二 08:07写道： > Hi, > > The discussion so far has landed on documenting which tools were used, the > review practices applied, and human ownership of changes. That's all well > and good, but it isn't what the ASF generative tooling guidance [1] > actually requires. For a contribution that includes AI-generated content, > the contributor needs to ensure that the tool's terms place no restrictions > on the output inconsistent with the Open Source Definition, that at least > one of the guidance's conditions on copyright and third-party material is > met, and that there's reasonable certainty of this. From the tool itself > providing information about output similar to its training data, or from > code scanning. Peer review and adversarial LLM review are good engineering > practices, but they address correctness and security, not the license > compatibility of the generated output. They don't satisfy any of these > conditions, and nothing said in the thread so far addresses them. > > So, for the initial import: which tools were used, have their terms been > checked against condition 1, and what code-scanning or tool-provided > training data exists to support the remaining conditions? If the answer is > "none yet", then that's what the committed provenance review needs to > produce, and it needs to be done, with anything that can't be established > removed or reimplemented, before the podling's first release. > > My larger concern is simpler: who is making the commits? Were the > bootstrap commits made by a person who reviewed each change before it went > in, or by agents running under a person's identity? A commit rate of > roughly 100 commits over three days by one developer makes genuine > per-commit human review hard to credit, and the ICLA representations attach > to the person named on the commit. Going forward, I'd want it stated > plainly: commits are made by human committers who have reviewed the change > and can stand behind it. Agents don't hold Apache accounts, and an LLM > review is not a committer review. > > None of this is an objection to AI-assisted development as such; it is > simply that existing guidance needs to be followed. There's also a broader > discussion to be had about what we expect of AI-native projects, and our > existing guidance may need to be updated, especially as new AI laws come > into effect. > > Thanks, > Justin > > [1] https://www.apache.org/legal/generative-tooling.html
