linux-kernel - Re: [PATCH 0/4] Add agent coding assistant configuration to Linux kernel

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <aId1oZn_KFaa0R_Q@lappy>
Date: Mon, 28 Jul 2025 09:05:37 -0400
From: Sasha Levin <sashal@...nel.org>
To: David Hildenbrand <david@...hat.com>
Cc: Greg KH <gregkh@...uxfoundation.org>, Vlastimil Babka <vbabka@...e.cz>,
	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 12:47:55PM +0200, David Hildenbrand wrote:
>We cannot keep complaining about maintainer overload and, at the same 
>time, encourage people to bombard us with even more of that stuff.
>
>Clearly flagging stuff as AI-generated can maybe help. But really, 
>what we need is a proper AI policy. I think QEMU did a good job 
>(again, maybe too strict, not sure).

So I've sent this series because I thought it's a parallel effort to the
effort of creating an "AI Policy".

Right now we already (implicitly) have a policy as far as these
contributions go, based on
https://www.linuxfoundation.org/legal/generative-ai and the lack of
other guidelines in our codebase, we effectively welcome AI generated
contributions without any other requirements beyond the ones that affect
a regular human.

This series of patches attempts to clarify that point to AI: it has to
follow the same requirements and rules that humans do.

>I'll note one interesting thing in the QEMU commit I linked:
>
>"Thus far though, this is has not been matched by a broadly
>accepted legal interpretation of the licensing implications for code
>generator outputs. While the vendors may claim there is no problem and
>a free choice of license is possible, they have an inherent conflict
>of interest in promoting this interpretation."
>
>[1] https://lkml.kernel.org/r/a4d8b292-154a-4d14-90e4-6c822acf1cfb@redhat.com

I get why QEMU did this: they don't have the resources, the lawyers, nor
the interest in dealing with this open question, so they're playing it
safe until we know more. That sounds like a very smart thing to do on
their end.

On our end, one of the reasons the kernel is part of the LF is to tackle
exactly this: none of us are lawyers, but luckily we have lawyers and
resources on our side to help us navigate these challanges.

I'd like to think that there's no conflict of interests within the LF,
and that their opinion on this matter best represents their client's
(both Linux Kernel as well as Linus's) best interests.

-- 
Thanks,
Sasha