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
