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: <aJC0ssMzX0KWnTkG@lappy>
Date: Mon, 4 Aug 2025 09:25:06 -0400
From: Sasha Levin <sashal@...nel.org>
To: Michal Hocko <mhocko@...e.com>
Cc: David Hildenbrand <david@...hat.com>,
	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, Aug 04, 2025 at 11:23:21AM +0200, Michal Hocko wrote:
>On Mon 28-07-25 09:05:37, Sasha Levin wrote:
>> 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.
>
>The above guidance is quite vague. How me as a maintainer should know
>that whatever AI tool has been used is meeting those two conditions

In exactly the same way you know that a human contributor didn't copy
code with an incompatible license.

Quoting from Documentation/process/5.Posting.rst :

	 - Signed-off-by: this is a developer's certification that he or
	   she has the right to submit the patch for inclusion into the
	   kernel.  It is an agreement to the Developer's Certificate of
	   Origin, the full text of which can be found in
	   :ref:`Documentation/process/submitting-patches.rst
	   <submittingpatches>` Code without a proper signoff cannot be
	   merged into the mainline.

The Signed-off-by tag doesn't mean that a commit was reviewed, it
doesn't mean that someone tested it, nor does it indicate that the
person who signed off belives it is correct.

It only means that the person has legally certified to you what is
stated in the DCO.

>: 1. Contributors should ensure that the terms and conditions of the
>: generative AI tool do not place any contractual restrictions on how the
>: tool’s output can be used that are inconsistent with the project’s open
>: source software license, the project’s intellectual property policies,
>: or the Open Source Definition.
>:
>: 2. If any pre-existing copyrighted materials (including pre-existing
>: open source code) authored or owned by third parties are included in the
>: AI tool’s output, prior to contributing such output to the project, the
>: Contributor should confirm that they have have permission from the third
>: party owners–such as the form of an open source license or public domain
>: declaration that complies with the project’s licensing policies–to use
>: and modify such pre-existing materials and contribute them to the
>: project. Additionally, the contributor should provide notice and
>: attribution of such third party rights, along with information about the
>: applicable license terms, with their contribution.
>
>Is that my responsibility?

As far as making sure that all patches you take come with a
Signed-off-by tag, yes, it's your responsibility to make sure that such
tag exists.

Otherwise, this series doesn't add any new requirements on you as a
maintainer.

-- 
Thanks,
Sasha

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ