[[[ To any NSA and FBI agents reading my email: please consider ]]]
[[[ whether defending the US Constitution against all enemies, ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]
> What you are saying is consistent with the GNU coding standard. However, I
> think any message about this would be annoying,
I am sure it would be a little annoying. But assuming the user can
type SPC and move on from that message, the annoyance will be quite
little.
personally, and would be a
> deterrent for clients to use this library.
If the library is quite useful I doubt anyone would be deterred.
If anyone minded it the message enough to stop using the package, perse could
edit this out of the code.
This issue is an example of those where two different values are
pertinent. There is convenience, which counts but is superficial.
And there is the purpose of the GNU system, which for 40 years has led
the fight against injustice in software. That value is deep and, in the
long term, the most important value of all.
When they conflict in a specific practical matter, there is always
pressure to prioritize convenience. But that is not wise.
The right approach is to look for a ocmpromise which serves both
goals. I am sure we can find one here.
I suggested showing the message once a day, because that is what first
occurred to me. But there are lots of ways to vary the details.
Here's an idea. For each language model, it could diisplay the
message the first, second, fifth, tenth, and after that every tenth
time the user starts that mode. With this, the frequency of little
annoyance will diminish soon, but the point will not be forgotten.
Is there anything else in emacs that does something similar? I'd like to look at how other modules do the same thing and how they communicate things to the user.
I believe we can output something, but at least some of the LLM calls are asynchronous, and, as a library, even when not async, we have no idea about the UI context we're in. Suddenly throwing up a window in a function that has no side-effects seems unfriendly to clients of the library. Perhaps we could just use the "warn" function, which is more in line with what might be expected from a library. And the user can suppress the warning if needed.
You made suggestions for how to exclude more code from Emacs itself,
and support for obscure language models we probably should exclude.
But there is no need to exclude the support for the well-known ones,
as I've explained.
And we can do better than that! We can educate the users about what
is wrong with those systems -- something that the media hysteria fails
to mention at all. That is important -- let's use Emacs for it!
> All implementations can then separately be made available on some other
> package library not associated with GNU. In this scenario, I wouldn't have
> warnings on those implementations, just as the many llm-based packages on
> various alternative ELPAs do not have warnings today.
They ought to show warnings -- the issue is exactly the same.
We should not slide quietly into acceptance and normalization of a new
systematic injustice. Opposing it is our job.
I don't doubt that or disagree, I'd just rather us oppose it in documentation or code comments, not during runtime. The other packages aren't under GNU control, and the authors may have different philosophies. It would be unfortunate if that worked out to the advantage of users, who have for whatever reason chosen to use a LLM provider being well aware that it is not a free system. I'm curious what others think.
--
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)