Message-ID: <aIdlnHcNHvOxVxGF@lappy>
Date: Mon, 28 Jul 2025 07:57:16 -0400
From: Sasha Levin <sashal@...nel.org>
To: Vlastimil Babka <vbabka@...e.cz>
Cc: corbet@....net, linux-doc@...r.kernel.org, workflows@...r.kernel.org,
	josh@...htriplett.org, kees@...nel.org,
	konstantin@...uxfoundation.org, linux-kernel@...r.kernel.org,
	rostedt@...dmis.org
Subject: Re: [PATCH 0/4] Add agent coding assistant configuration to Linux
 kernel

On Mon, Jul 28, 2025 at 09:58:44AM +0200, Vlastimil Babka wrote:
>On 7/27/25 21:57, Sasha Levin wrote:
>> This patch series adds unified configuration and documentation for coding
>> agents working with the Linux kernel codebase. As coding agents
>> become increasingly common in software development, it's important to
>> establish clear guidelines for their use in kernel development.
>
>Hi,
>
>this series seems to me somewhat premature. I think we first need a clear
>policy wrt LLM usage for the *humans* to follow. It seemed this thread [1]
>was going into that direction wrt usage disclosure. BTW I was quite shocked
>by Steven's reply there [2] that he learned from the LWN coverage of a
>conference talk that he had received a patch fully written by LLM without
>any such indication. Now I'm not naive to believe that it's not been
>happening already from e.g. first-time contributors, but if that coverage
>was accurate, the patch came from a very seasoned kernel contributor and I
>really wouldn't expect that to happen.

You mean that you had a concern that the same person who wrote
hashtable.h was using tooling to convert open coded implementations of a
hashtable to the API provided by hashtable.h?

I've been doing this since 2012 (see 42f8570f437b ("workqueue: use new
hashtable implementation")) with the various tools that the we have for
mechanical transmormations of code.

I understand Steve's point of view on this, and this series is here to
tackle the concerns raised both by him and the rest of the community.

>Also I don't know e.g. the copyright and licensing implications of LLM usage
>beyond, say, a smarter automplete are clear? (again, such as writing the
>full patch?) The thread [1] touched on it somewhat but not completely. If
>that's clear already (IANAL), I'd hope that to be also part of such policy.

The LF already has guidance
(https://www.linuxfoundation.org/legal/generative-ai) for this type of
contributions that was created by LF's lawyers.

Clearly we can override, expand, or affirm it if we want to, but just
like you, IANAL.

>I know that your series has patch 4, but that seems to be part of what the
>LLM is supposed to include for its prompt (does it make sense to call it
>"legal requirements" then?). If it fails to e.g. add the "Co-developed-by:"
>there seems to be nothing saying the human should check these things in the
>output.

Right - as pointed to later in the thread, that part is already in
progress.

The approach in this series would be to cover the technical aspects of
supporting whatever policy we end up with.

>So without such policy first, I fear just merging this alone would send the
>message that the kernel is now officially accepting contributions done with
>coding assistants, and those assistants will do the right things based on
>these configuration files, and the developers using the assistants don't
>need to concern themselves with anything more, as it's all covered by the
>configuration.

Note that at the current state of our policies and documentation, if you
were to pretend to be a developer completely unfamiliar with the Linux
Kernel project, the conclusion you'd reach is that the project
"officially" accepts contributions that are in line with LF's policies.

If anything, this series clamps down on that.

-- 
Thanks,
Sasha

Powered by blists - more mailing lists