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)
• Discussion on the CRA topic (see last board thread)

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 1^st 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: 2^nd 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.