Re: GCC LLM policy adopted

Matthias Geiger <[email protected]> Fri, 31 Jul 2026 16:00:51 +0200
Newsgroups gmane.linux.debian.devel.vote
Message-ID <[email protected]>
On Fri, 31 Jul 2026 15:40, Adrian Bunk <[email protected]> wrote:
>On Fri, Jul 31, 2026 at 10:56:18AM +0200, Gard Spreemann wrote:
>> Gard Spreemann <[email protected]> writes:
>> 
>> > Russ Allbery <[email protected]> writes:
>> >
>
>This draft option also applies to upstream code.
>
>There is an important difference between GCC and us:
>We are a collection of upstream sources in an ecosystem where usage of
>AI-generated code is no longer rare, with our own code parts being 
>rather small compared to the upstream code we include.
>
>The fundamental problem with all anti-AI proposals is that there are 
>good arguments against inclusion of AI-generated code at least for now,[1]
>but the consequence of applying this also to upstream code in main would 
>not be workable.
>
This has been the main scope of my argument too: We simply can't allow 
something with such unclear legal status for our tooling. For linux that 
sip has unfortunately sailed, and we can't ban the kernel that we all 
use.
>Trying to apply such rules only to Debian-specific parts would have 
>consequences like banning AI-generated test cases under debian/tests/,
>but the maintainer submitting this code upstream and then backporting 
>the same code would be fine.
>
This is a problem indeed, but if someone wants to cheat that way ...
>
>[1] personally I would consider the unclear copyright status sufficient
>
100 % this. While I personally consider the resource usage more 
important, the licensing issues are not clear at all.
The DFSG were instituted for a reason. Allowing code with such murky 
licensing for our core tooling is IMO a direct violation of the DFSG.


best,