glibc AI policy

[Florian Weimer]

* Jeffrey Law:

>> Has the FSF communicated this (not accepting LLM-generated
>> contributions for now) to the glibc stewards?

This question is still open.

>> Why would the de-minimis guidelines apply, anyway?  I assume those
>> are about not diluting the copyright assignment, but that's hardly a
>> concern for GNU components accepting contributions under the DCO.
>
> A de-minimis contribution is (at least in the US) considered so
> trivial that is not copyrightable, so I'd tend to suspect such
> contributions, even from LLMs, wouldn't be a problem under the FSF's
> de-minimis guidelines of 5 lines of code.  Of course de-minimis
> contributions in aggregate may cross the threshold into copyrightable.

Isn't the concern about infringement, which is separate from being
copyrightable?  An infringing contribution is not copyrightable, either.

Anyway, I think for a large range of possible applications of code
auto-generation, this seems rather unlikely to matter.  Consider the
test case in this patch:

  [PATCH v2] Use pending character state in IBM1390, IBM1399 character
  sets (CVE-2026-4046)
  <https://inbox.sourceware.org/libc-alpha/lhucy0b6l2w.fsf@oldenburg.str.redhat.com/>

This code is heavily dependent on internal glibc interfaces not
available anywhere else.  The abstract structure of the iconv loops
exist in many other places, but that's about it.  The implementation is
not overly bloated, either.

Why wouldn't we want to accept code like this?

Maybe that's the reason why the FSF hasn't told us to pause accepting
auto-generated contributions immediately.

Thanks,
Florian