Hi Ian,
On 10/5/26 05:29, Ian Eure wrote:
- Should Guix label software it packages as containing LLM output?
First my thoughts on this, and below a note on the meta-discussion.
As a practical matter, you cannot "filter out" such packages, as it
would produce an unusable system, because it would contain the Linux
kernel.
Thanks for clarifying. If we anticipate that most, if not all, people
would still use packages with LLM-generated output, then I would propose
a more detailed labeling than a binary flag.
E.g. for me personally it is more important that the code has been read
and vetted by a human than whether it is written by a human. Mainly
because I believe we primarily write 'for' humans. I fear the "freedom
to study" could effectively become undermined when de-facto not even the
'authors' of the software have 'studied' their code.
Guix is the first operating system where I feel that it might be
achievable to understand everything, it would be great if we can extend
that to software we package.
There are also copyright concerns (freedom to copy), and I anticipate
those also require more than a binary flag, because I expect society as
a whole will decide that certain use of AI agents will be fine copyright
wise.
If no LLM-generated code can ever be free, then we don't need this flag,
because we cannot incorporate those packages at all. So for the sake of
the discussion we should assume that it will be decided that
LLM-generated code can be free software.
An example to make the issue more concrete: if someone uses an LLM to
fix an off-by-one error (in software we package, let's ignore Guix
itself), and they would explicitly note that in their release notes.
Would we add this 'contains-LLM-output' flag for that package?
Flagging such trivial LLM-use would make the flag useless to me. I'm
not sure it will be feasible to achieve consensus on what we should
flag, but I'm willing to try.
Let's be constructive. Values that I can see w.r.t. to 'uses LLM output':
10) No LLM output used at all.
20) Small bits of LLM-generated code, e.g. agents reviewing human code.
30) Large code parts LLM-generated, but read and verified by a human.
40) Mostly vibe-coded and not read by a human.
I think those are a fair assessment of different approaches a project
could take. Someone must have done a study on that. Anyway, old-school
line numbers so people can easily interject their own.
Again, this list assumes that the copyright debate will be resolved, and
that some LLM use will be fine copyright wise. Because we only need the
flag for software that is eligible to be included in Guix to begin with.
What flag values would you all be comfortable with?
I do agree that it would be somewhat ridiculous to include Guix in the
list
That's a nice rephrasing. I think that both side of the debate would
find flagging Guix ridiculous. Which is perhaps the essence of the
discussion.
Hugo
On the meta discussion, because you explicitly asked a question:
>> Because what would be the point of labeling if Guix itself can include
>> LLM output? Technically nothing, we would just label the `guix`
>> package. But in practice, who would both use Guix and filter out the
>> LLM-flagged packages, when that would mean filtering out Guix?
>
> Can you point me to any proposal to use the property to "filter out"
> packages? I haven’t propsed this, and am not aware of anyone else
> having done so.
The first question in the quoted paragraph is the important one: "What
would be the point?"; perhaps I phrased that in a way that can easily be
read as passive aggressive, but essentially it is sincere. The second
question is essentially a more precise reframe, purposefully not
literally what anyone said, to highlight my confusion w.r.t. what we are
trying to achieve with the labeling.
That is, the sentence you responded to is deliberately more precise at
the risk of being less accurate, exactly to identify where it might be
inaccurate.
