Re: GCC LLM policy adopted

On Fri, Jul 31, 2026 at 04:00:51PM +0200, Matthias Geiger wrote:
> 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.

It is not only the kernel.

My main work in Debian is QA (mostly RC bug fixing), and I am 
usually looking at dozens of upstream git repositories every
week searching for fixes.
Seeing commits mention Claude (or other AI) is pretty common,
and this has already arrived in our archive:
[2] alone finds 70 packages, and that's just one of many ways how 
upstreams explain to AI how to work with their code.
I have no data how much of this is only for code review,
but commits or MRs mentioning that the code was AI-generated
are not uncommon.

> > 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.

The DFSG do apply to all upstream sources in main.

> best,

cu
Adrian

[2] https://codesearch.debian.net/search?q=This+file+provides+guidance+to+Claude+Code&literal=1