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 threadhttps://lists.trustedfirmware.org/archives/list/board@lists.trustedfirmware.org/thread/LN6LSFIIFNIFFPLBOBKPV7GD7KE5IVQ2/) * Discussion on the CRA topic (see last board threadhttps://lists.trustedfirmware.org/archives/list/board@lists.trustedfirmware.org/thread/VV7GI3DABVBGHDZXZJQVMEMXZT7WANAP/)

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.