glibc AI policy

[Sam James]

Florian Weimer <fweimer@redhat.com> writes:

> * 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?

My only concern would be "vacuous" tests where they're not actually
testing what we need them to, or aren't sufficiently adversarial.

If used responsibly, I'm not really concerned about such use like your
example.

> [...]

sam
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 418 bytes
Desc: not available
URL: <https://sourceware.org/pipermail/libc-alpha/attachments/20260407/8d423c37/attachment-0001.sig>