Hi Thanos,
<#secure method=pgpmime mode=sign>
Thanos Apollo <[email protected]> writes:
Ian Eure <[email protected]> writes:
There are two issues:
- Should Guix allow contributions including LLM output?
- Should Guix label software it packages as containing LLM
output?
I think both questions share a premise worth pushing back on:
that the
tooling used to write code is something a distribution should
care
about.
It matters because the provenence of the code is different. Prior
to LLMs, "tool" meant, say, nano, or vi, or Emacs, or a
typewriter, or some other thing which a human used to directly
create the code. In that scenario, I agree, the tool does not
matter. This situation is entirely different, as the provenance
of the code no longer ends at the contributor, because they did
not create it. Thus, there is a substantial risk of bugs due to
inattention, or of the code not being copyrightable, or containing
infringing material.
The four freedoms are about the artifact, not the process.
It is both process and artifact, as the one produces the other.
If my process for creating software is to reuse as much infringing
code as possible, the created software is tainted because of that,
and its users bear some risk -- even if the risk is merely that
they can no longer use it.
Run, study, modify, share. They say nothing about the editor,
the
compiler vendor, or whether the author used grep or ripgrep.
This is a false comparison, because those are tools used by
humans. Humans do not create LLM output. That’s the whole point
of them.
"Was an LLM involved" isn't a useful proxy for the things we
actually
care about. Licensing? We review for it. Plenty of LLM output
is
original, and plenty of hand-written code is a copy-paste from
Stack
Overflow or intentional copyright violation.
I am consistent in that I also do not want contributions
containing intentional infringement. The difference is that the
industrial scale at which LLMs can produce output dramatically
changes the risk profile vs. what one person can copy-paste
(intentionally or not).
So what would the label actually warn users about?
That it may contain LLM output, which is a thing many people do
not want and seek minimize or to avoid outright. Such as the user
who started this thread asking for this. This is identical to how
F-Droid hosts Android software, but tells you about its
anti-features.
People who like LLMs seem to really like them, so it strikes me as
quite odd that they would be against a property indicating that
they were used. Such a thing seems like it would be a mark of
pride.
Not correctness, not licensing, not security; we test, audit,
and
review for those. What's left is a sociological signal: this
author
touched a tool some of us dislike. That's not a property of the
software, and I don't think it belongs in package metadata.
I don’t believe Guix does testing at anywhere near the level of
the developer of the package, and as a professional software
developer in 2026, I can assure you with an extremely high degree
of confidence that among LLM users, fewer are paying attention to
these things than ever before; many are delgating that task to
LLMs as well. It’s a legitimate risk profile, and I’ve seen the
incident response to prove it.
Once you start labelling software by properties of its authors
rather
than properties of itself, it's hard to say where that stops.
Where the supposed "authors" of LLM contributions are not human, I
fail to see a meaningful difference.
-- Ian
