Re: [PATCH] CONTRIBUTING.d/ai: Add guidelines banning AI for contributing

[Alejandro Colomar <alx@kernel.org>]

[-- Attachment #1: Type: text/plain, Size: 3998 bytes --]

Hi Günther!

On 2026-03-29T15:42:03+0200, Günther Noack wrote:
> Hello!
> 
> On Tue, Oct 14, 2025 at 11:27:26PM +0200, Alejandro Colomar wrote:
> > Signed-off-by: Alejandro Colomar <alx@kernel.org>
> > ---
> > 
> > Hi!
> > 
> > I've already been DDoSed in my own home server by AI crawlers (which is
> > the reason I decided to move the HTTPS server to port 80, just to break
> > links and stop the madness.  I could install Anubis, but I'll resist for
> > some time.
> > 
> > So far, I haven't noticed any contributors using AI.  Probably, the
> > combination of relatively few people contributing documentation,
> > combined with still working on a mailing list, has helped us avoid the
> > wave of AI contributions.
> > 
> > However, it's better to take preventive measures.  AI is entirely banned
> > in this project.  The guidelines are clear and concise.
> 
> I know I'm late to the discussion, but for the record, I would like to
> throw a scenario into the discussion that I consider a compelling use
> case for AI-assisted man-page contributions.
> 
> As you know, the Landlock man page work mainly consists of taking the
> existing kernel documentation text and putting it into the man page
> form.  That means that when producing the man page patches, the main
> additional work is:
> 
> (a) formatting existing text in groff
> (b) adapting the structure to match the man page format
> (c) copy-and-pasting wording fixes between kernel and man page tree
>     (in either direction)
> 
> Because this is tedious and time-consuming, and because the added
> value over the existing kernel documentation is low, Landlock's man
> pages tend to lag behind the kernel documentation by many months.
> 
> Coding agents are very good at such reformatting tasks though, and
> that would make it potentially feasible to keep this up to date much
> faster.  (with the rough process being that you point a coding agent
> to the man page and Linux source trees and ask it to carry the
> documentation changes over in a way that respects existing man page
> style and structure). [^1]
> 
> Since the submitted man page text is the same as on the kernel side,
> the main work done by the agent here is in Groff formatting, and in
> finding the text in the kernel tree and putting it into the right man
> page structure.
> 
> For inspiration, the Linux kernel itself has, after substantial
> discussion, recently started adopting a different policy, where
> AI-generated contributions are permitted, but where it is still made
> clear that human contributors must review all AI-generated code and
> have the same responsibilities as for a normal human-authored patch:
> 
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/process/coding-assistants.rst
> 
> I realize that the Landlock use case alone is maybe not enough to
> change your stance on this, but I feel it's worth at least pointing
> out that there are use cases with potential upsides.
> 
> I think that with a Linux-like policy for coding assistants, it would
> be easier for us to keep the man pages up to date.

Thanks for the suggestion.  I'm certainly less worried about this
specific use case than for anything else.  But I still don't think it
would be a good idea.  And the ethical concerns remain.  Let's keep the
anti-AI policy.

> –Günther
> 
> 
> Footnotes
> 
> [^1] An alternative that has been considered in the past was to create
>      a mechanistic translation program to create the man pages from
>      kernel .rst and .h files, but this also seems brittle and would
>      mean that the man page structure would likely stay close to the
>      kernel documentation in structure.  In my understanding, Linux's
>      eBPF helpers use that approach.

Yes, bpf-helpers(7) does that.  I hate it, but I prefer it over AI.  :)


Have a lovely day!
Alex

-- 
<https://www.alejandro-colomar.es>

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]