Present:
Dan Handley (Arm)
Shebu Varghese Kuriakose (Arm)
Joanna Farley (Arm)
Eric Finco (ST)
P J Bringer (ProvenRun)
KangKang Shen (FutureWei)
Andrew Davis (TI)
Dhruva Gole (TI)
Kamlesh Gurudasani (TI)
Agenda:
* Feedback on draft guidance for AI contributions (see board thread<https://lists.trustedfirmware.org/archives/list/board@lists.trustedfirmware…>)
* Discussion on the CRA topic (see last board thread<https://lists.trustedfirmware.org/archives/list/board@lists.trustedfirmware…>)
Shebu: Hopefully everyone has seen the draft AI code generation policy I sent
Shebu: Eric - can you summarise your feedback?
Eric: 2 things. One, can we signal that the contribution has used an AI assistant?
Eric: One reason is the EU act recommends transparency. We (ST) also believe transparency is a good reason.
Eric: Other feedback is we don't see a strong reason to allow projects to deviate from policy.
Eric: Think it would be more consistent to have same policy across all TF.org projects.
Shebu: On 1st item, is the signal to the maintainer or the consumer?
Eric: Primarily to the maintainer.
Shebu: We looked at Linux Foundation, Apache and other policies. Apache does recommend it's generated by a particular tool.
Shebu: But people can still decide not to put in attributions.
Shebu: Should attribution be in the patches themselves (commit messages) or some separate message?
Eric: No strong opinion on this. Either works. More widely available if it's in the commit message.
Shebu: No consortium is mandating this. Only 1 is recommending it.
Eric: Agree it's hard to enforce. Would just be declarative.
Shebu: The primary concern of other consortiums was that the contributor is responsible for where their contribution comes from.
Shebu: Not sure if having the attribution implies we'll do something with those attributions?
Eric: Would just be informative information.
Eric: Agree it's up to the contributor to take responsibility
KK: AI is moving very fast. We really don't know where people got the code.
KK: We have to be clear it's the contributor that is responsible.
KK: I just went to Confidential Compute conference.
KK: Everything was about AI, e.g. Agentic AI
KK: Most companies are concerned about not releasing their confidential information.
KK: If you're working in the open world, you don't have that risk. Need to have that separation.
KK: There are many companies using many different tools. Rule needs to be as simple as possible.
KK: OpenAI CEO thinks AI coding will be pervasive by the end of the year.
KK described other leading edge developments in the world of AI, e.g. agentic assistants.
Shebu: So do you (KK) think we should avoid attribution.
KK: Yes, we shouldn't care where it come from. It may be hard to gather all the details on how the patch was generated.
Shebu: No policies so far have suggested changes to DCO or other contribution terms.
Shebu: Agree that if someone is using agentic assistant, then attribution may be hard to produce.
KK: A bunch of AI engines may have been involved in the development workflow. Not a one-shot thing.
Shebu: Best we could do is a recommendation. But we wouldn't want to limit contributions because of this.
Shebu: Could having this cause a misconception that the code is fully auditable?
KK: Even in current workflow, if multiple engineers contribute, the final committer takes overall responsibility.
Shebu: Can follow this up at the board meeting.
Shebu: 2nd piece of feedback was about having a global TF.org policy
Shebu: Again, this option for projects to deviate came from the Linux Foundation guidance.
Shebu: This policy has only been reviewed by board and TSC
Shebu: Project maintainers may have different opinions. We haven't asked them yet.
Shebu: Difficult to assess as there is a large community of maintainers across all projects.
Dan: We certainly would need to get more maintainer buy-in if we removed this option to deviate.
Dan: We want to get their feedback anyway but especially important if we're trying to force this on them.
Dan: Any thoughts on how we should gather that feedback?
KK: Just ask all the maintainers
KK: Used to be able to write ~10 LOC/day. Now can do much more, especially for example test suites.
Joanna: If you have a big maintainer pool, might not get much response.
Joanna: Suggest getting a smaller pool or approaching each project individually.
Dan: OK, will wait for outcome of board meeting then send latest draft and open issues to (some) project maintainers.
Dan: Eric last month sent some interesting links on CRA implications/recommendations
Eric: CRA has recommendations around security policy and SBOMs.
Eric: Also, something around auditing (including SBOMs).
Shebu: Looking at those materials and recent Linaro Connect materials, should we start looking at SBOM generation at TF.org?
Shebu: Or wait for more developments/requirements?
Eric: One thing we could discuss is settling on SBOM format (CycloneX or SPDX).
Dan: And tooling to use?
Eric: Afterwards, yes.
Dan: Should we be doing more in terms of integration at TF.org (e.g. using Yocto) rather than devolving this to component projects?
PJ: Eric - are you aware of similar projects and the format they chose?
Eric: Think Yocto and Zephyr are using SPDX (would need to double check).
PJ: I could investigate this offline.
Dan: Yes, thanks!
KK: Companies that use TF.org take final responsibility for accuracy.
KK: They can't trust TF.org to have done the right thing and TF.org shouldn't take responsibility.
KK: But it's good if TF.org can help avoid duplication by companies.
