Re: GR: Ban LLM contributions from Debian

Hi,

23 Jul 2026 03:42:41 Andrey Rakhmatullin <[email protected]>:

> I haven't researched why did Linux decide to do this (it may have 
> something to do with the unique Linux-specific culture of adding all 
> sorts of metadata to submitted patches?) but I don't see much value in 
> it, besides being helpful to deprioritize submissions produced with 
> garbage level models.

Preserving this metadata is a valid way to handle the legal uncertainty 
about whether LLM output can ever be copyrightable, even if assisted by 
a human — because there is no line-by-line attribution, and the concept 
of that would be nonsensical, we must assume the entire contribution to 
be either copyrightable or uncopyrightable as a whole.

By carefully documenting that only certain changes have questionable 
status, the hope is that the legal protection, whatever that is still 
worth, is kept for all other contributions.

For a codebase that does not make that distinction, I believe it will be 
very difficult to claim any form of copyright[1], much less apply a 
licence to it. That does not stop us from distributing it, the public 
domain is still DFSG-free, so we do not need to make this distinction 
for the software shipped in the archive. From a licence point of view, 
Debian is also not different from its upstream projects.

The problems are elsewhere, in project management, and in the external 
effects of AI usage.

My expectation is that we will see more zombie projects that are 
effectively unmaintained but still have releases, as people submit PRs 
for specific problems which get accepted as long as the tests are 
passing, but no actual project management is happening — but that has 
always been a problem, LLMs just amplify it.

That's why I'm always sceptical of efforts to make it easier to do 
drive-by contributions. There is no bottleneck in Debian that can be 
solved by making it more easy to keep a zombie package alive for a few 
more months, and so neither a "familiar" forge based merge request 
workflow nor embracing LLMs for packaging tasks provides an improvement: 
they solve a problem we don't have.

Where we have boilerplate, the best thing to do is to build a tool that 
takes care of the common case and leaves an escape hatch for uncommon 
ones, such as debhelper. A boilerplate generator is a lot less useful in 
comparison, and one that forces me to review its output even less so.

For many of my packages, updating the debian/copyright file has become 
the biggest time sink, precisely because the tools we have generate 
something that is 90% correct, and I then need time to manually look for 
discrepancies.

The *actual* bottleneck for us is knowledge transfer, precisely the 
thing that LLMs disrupt, by taking our capacity for reviewing others' 
work, redirecting it to solitary tasks instead, and discarding the 
feedback after it rotates out of the context window. We still go through 
the effort of training someone, but the "new contributor" will always be 
limited to work under close supervision, and availability depends on 
continued sponsorship by a large corporation.

That is not sustainable for Debian. Our goal isn't to ship the most 
packages in the next quarter, but to build a resilient community 
distribution that can still function in ten years regardless of what the 
political or economic reality of the world will be by then.

And, speaking of sustainability, the most important point: our AI policy 
is also a statement on whether we believe the efficiency[2] gains are 
worth the resource usage. We cannot remain neutral on this topic.

We have already taken the position that the additional resource usage on 
our own servers is inacceptable, and have therefore added an Anubis 
frontend to block AI crawlers. A consistent position that embraces AI 
should include provisioning adequate training data, either by allowing 
crawlers unrestricted access to Debian infrastructure, or by entering 
into an explicit data sharing agreement.

Such a position would also include a statement that we believe the 
resource usage in land, water, energy and material to be adequate for 
the value it provides to free software and its users, including those in 
the areas where new datacenters are being built.

We cannot avoid making such a statement, because the resource usage is 
well known at this point, these services are by no means essential, in 
fact, I believe we still require applicants to go through the New 
Maintainer process without AI assistance, so that every Debian Developer 
is perfectly capable of working without AI.

Not addressing this aspect at all in a resolution is a statement in 
itself[3].

    Simon

[1] realistically, we can expect the US legal system to settle on "LLM 
outputs are unrelated to training data and not copyrightable", even if 
we know better -- because the alternative would be "LLM outputs are 
derived from works under conflicting licences and therefore 
undistributable", and we all know which side the expensive lawyers will 
be on.

[2] the opposite of resiliency

[3] 
https://media.ccc.de/v/30C3_-_5491_-_en_-_saal_1_-_201312272300_-_no_neutral_ground_in_a_burning_world_-_quinn_norton_-_eleanor_saitta