Hi Greg,
Greg Hogan <[email protected]> writes:
On Wed, May 6, 2026 at 4:21 PM Ian Eure <[email protected]>
wrote:
Hi Greg,
Greg Hogan <[email protected]> writes:
> On Wed, May 6, 2026 at 10:07 AM Ian Eure <[email protected]>
> wrote:
> [...]
>> What I proposed is completely neutral: people declare
>> whether
>> the
>> package uses LLM output. If you dislike LLM output, you can
>> take
>> steps to minimize it. If you like LLM output, you can take
>> steps
>> to maximize it. Obligation to declare has zero effect on
>> obligation to use (or not).
>
> Guix packages define the properties needed to use the
> software. Your
> proposal is to start including additional metadata orthogonal
> to
> software freedoms.
The 0th of the four essential freedoms[1] is:
The freedom to run the program as you wish, for any
purpose.
And the more lengthy explanation of this freedom states:
“As you wish” includes, optionally, “not at all” if that is
what
you wish. So there is no need for a separate “freedom not
to
run a
program.”
Because many people wish not to run software containing LLM
output,
the proposed property directly supports this freedom.
No one here is restricting your freedom to selectively run
software as you wish.
Since I’ve never claimed this, I don’t see the relevance.
What you are proposing is to mandate that others write software
to
your personal desires, in violation of their 1st software
freedom:
Do you also object to declaring the license of the packaged
software in its Guix package definition? This is the same thing
as what I propose, that a factual property of the packaged
software be encoded in its Guix package definition. An objection
to one logically applies to the other.
The freedom to study how the program works, and change it so
it does your computing as you wish (freedom 1). Access to
the source code is a precondition for this.
> The clear alternative is to use the existing
> external datasets previously referenced to filter your own
> package
> manifests. Then no one is obliged.
Adding a single boolean flag to only packages containing LLM
output
does not strike me as a particularly weighty obligation.
What are the specifics of your single boolean flag?
(define-public some-package
(package
...
(properties
((#:includes-llm-output? . #t)))))
This is for output from any LLM model?
Yes.
Others may be fine with LLM output when the model is open
weights,
or when trained on explicitly licensed data. There are
additional
dimensions. Others may not even want the software to have been
reviewed by an LLM. Or the the developer(s) make use of LLMs
tangential to the software development.
I agree, they may. I don’t think it’s worth capturing those
dimensions, but I do think the baseline of including LLM output or
not is useful.
Then there is the question of why only the LLM bit should be
tracked.
Quoting myself:
"Because many people wish not to run software containing LLM
output..."
...as evidenced by the discussions of the subject on this list,
including this one, the open slopware list, and the many negative
reactions to software incorporating LLM output, many of which are
plainly visible in the issues linked on that list.
What of criminals, perhaps someone prefers not to run software
written
by a criminal. But have they served their time? Unless they
harmed
children, perhaps that is unforgivable but by God. What if
someone has
harmed children but not as a crime in their own country?
Do people wish not to run this type of software on the scale of
those who wish not to run software containing LLM output? I will
posit that, no, they do not.
But if you were to point me to an "open-written-by-criminalware"
lists containing a similar level of objection to this kind of
software, I would absolutely support discussing whether we should
be transparent about that to our users.
Or worse, what if a software developer has wrong thoughts, not
yet
criminalized everywhere? Or even thinks for him- or herself?
Yes,
it's all a bit ridiculous.
Please keep things on topic.
-- Ian
