HI, > Can you expand on what condition 1 is? I can see some numbered items on [1] > but would ask for clarification.
On condition 1: I was referring to the numbered conditions on the generative tooling page. Condition 1 is that the terms and conditions of the AI tool place no restrictions on use of the output that would be inconsistent with the Open Source Definition. It's a per-tool check of the vendor's terms of use, which is why knowing which tools were used matters. > 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. On scanning: agreed, SCANOSS works well, and other projects use this on AI-generated code. One caution on peer review though: a reviewer recognising that a snippet is written the conventional way is evidence of quality, not of provenance. Conventional code is exactly what a model generates from its training data. Review helps condition 1 not at all and conditions 2.2/2.3 only weakly; scanning is the mechanism the guidance points at. You cannot rely on review for this. >> 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. On the commit rate, I think my point got lost. The hundred commits in a day are not a concern. The question is: for each contribution, is there a human who reviewed the change, decided to submit it, and whose ICLA representations apply to it? Our whole licensing chain assumes that person exists and does the commit. The ICLA and SGA are agreements with people; an agent can't make the clause 4 representations, and a model reviewing another model's output doesn't create accountability. Existing Infrastructure policy already governs automation: in general, only committers may push commits to repositories, and automated services must not push to any repository or branch subject to official release as a software package unless the project secures specific prior authorization from Infrastructure. Agents are automated services under this policy. It follows that an agent should never commit code in an ASF project, and you should never give an agent your ASF credentials. Agents and other automation may propose changes, but every commit that enters a project is made by a human committer who has reviewed the change and takes responsibility for it, including the ICLA representations that apply to it. Running an agent under your own credentials does not change this: a commit made under your identity carries your personal review and your representations, so lending your credentials to an agent is a policy violation, not a workflow choice. If the developer reviewed each step, the dense history is fine, and I have no issue with it, as I said. If they didn't, squashing the commits doesn't change that; it just makes it impossible for anyone to tell. It also runs counter to the guidance's own recommendation to record tooling in commit messages using a Generated-by token. So the ask isn't tidy history. It's that the proposal states plainly that every contribution has a human contributor of record who reviewed it and stands behind it, regardless of the tools involved. Kind regards, Justin
