[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20250724220241.21b5d5f8@gandalf.local.home>
Date: Thu, 24 Jul 2025 22:02:41 -0400
From: Steven Rostedt <rostedt@...dmis.org>
To: Sasha Levin <sashal@...nel.org>
Cc: "Dr. David Alan Gilbert" <linux@...blig.org>, Kees Cook
<kees@...nel.org>, Konstantin Ryabitsev <konstantin@...uxfoundation.org>,
corbet@....net, workflows@...r.kernel.org, josh@...htriplett.org,
linux-doc@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [RFC PATCH] docs: submitting-patches: (AI?) Tool disclosure tag
On Thu, 24 Jul 2025 21:52:12 -0400
Sasha Levin <sashal@...nel.org> wrote:
> We'll be hitting these issues all over the place if we try and draw a
> line... For example, with more advances autocompletion: where would you
> draw the line between completing variable names and writing an entire
> function based on a comment I've made?
It's not much different than the "copyright" issue. How much code do I have
to copy before I start infringing on someone's copyright?
But if you start using tooling to come up with algorithms that you would
not think of on your own, then you definitely should document it.
Heck, I do it now even for algorithms I get from a book. I'll credit Knuth
on stuff all the time. Same should happen if you get something from AI.
It's one thing if it finds a bug or formatting issue, it's something
completely different if it starts coming up with the algorithms for you.
And even if it is trivial, if you had it do most of the work, you most
definitely should disclose it.
-- Steve
Powered by blists - more mailing lists