Re: [PATCH RFC] coding-assistants: simplify attribution

[Carlos Maiolino <cem@kernel.org>]

On Thu, Jul 02, 2026 at 10:28:13AM +0200, Christian Brauner wrote:
> On 2026-07-02 11:08 +0300, Laurent Pinchart wrote:
> > On Thu, Jul 02, 2026 at 09:27:37AM +0200, Christian Brauner wrote:
> > > > What would be much more relevant to know is to which degree LLMs were used.
> > > > 
> > > > Assisted-by: LLM # translate commit message
> > > > Assisted-by: LLM # generate some test cases
> > > > Assisted-by: LLM # cleanup logic
> > > > Assisted-by: LLM # everything and I have no clue what any in here does
> > > 
> > > I think we should just drop any attribution as a general kernel-wide
> > > rule and let subsystems require them as needed. Then you can have all
> > > the complexity in mm for this that you think is needed for your
> > > workflow to function. This is precisely what the subsystem profiles are
> > > for. So maybe just add:
> > > 
> > > Documentation/process/maintainer-mm.rst
> > > 
> > > alongside
> > > 
> > > Documentation/process/maintainer-{tip,netdev,x86}.rst
> > > 
> > > and lay down the rules that you require for LLM based submissions in
> > > whatever detail you need.
> > > 
> > > I don't see how this additional commentary you want would ever be
> > > enforced consistently across the kernel or who would even enforce it. I
> > > don't need more beaurocracy to chase after people in my subsystems tbh.
> > > 
> > > The other thing is that I think this Assisted-by annotation is just
> > > noise in the changelog. If you want to know in detail what an LLM was
> > > used for when generating the patch it's mostly a signal for how
> > > "intense" of a review this will get afaict (already questionable imho
> > > but sure that's just something to disagree on).
> > > 
> > > If the information is mostly useful during review then I still would
> > > question why it has to end up in our git logs. It's completely
> > > irrelevant information imho.
> > 
> > Food for thought, the Kubernetes project has published a disclosure
> > policy ([1], reported by LWN.net at [2], with a blog post explaininig it
> > at [3]). Quoting LWN.net,
> > 
> > "Of note, the project requires disclosure when AI tools have been used
> > to assist in the creation of a contribution but forbids the use of
> > listing AI as a co-author or including "assisted-by" or "co-developed"
> > trailers to attribute work to an LLM tool."
> > 
> > I personally don't see a lot of value in the Assisted-by trailer, but I
> > would like the submitter to include the information in a place that
> > doesn't end up in the git commit history (cover letter or below the ---
> > line).
> 
> Fwiw, way before k8s I had systemd adopt the following policy:
> 
> https://github.com/systemd/systemd/blob/main/docs/CONTRIBUTING.md#policy-on-the-use-of-large-language-models-llms-and-ai-tooling
> 
>     We expect everyone contributing to systemd to fully own their
>     contribution, be able to reason about it, be able to explain why things
>     were done a particular way and act as the full owner of that code. AI
>     tools are treated the same as traditional tooling like sed, awk or
>     coccinelle.
> 
>     For the purpose of this project, AI tools CANNOT be treated as author,
>     co-author or be credited in any way that would suggest any ownership
>     over the contribution.
> 
>     The contributor should have done all the thinking, planning and
>     understanding of the changes needed to resolve an issue or implement a
>     new feature prior to using automated tooling to perform the grunt work.
> 
>     Unguided use of those tools or the inability to prove understanding of
>     the code contributed will result in a loss of trust in that contributor
>     by project maintainers which can then lead to exclusion from any further
>     contribution to the project.
> 
>     As with any other submissions, authors are responsible for doing due
>     diligence and ensuring their submissions are compatible with the
>     project's license as documented in LICENSES/README.md.
> 
> 

This sounds very reasonable to me.