[[[ 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. ]]]
All the large language models are unjust -- either the models
are nonfree software, released under a license that denies freedom 0
(https://www.gnu.org/philosophy/programs-must-not-limit-freedom-to-run.html),
or they are not released at all, only made available for use as SaaSS
(https://www.gnu.org/philosophy/who-does-that-server-really-serve.html).
If a language model is much better known that GNU Emacs,
it is ok to have code in Emacs to make it more convenient
to use Emacs along with the language model. If the language model
is not so well known, then Emacs should not mention it _in any way_.
This is in the GNU coding standards.
If Emacs is to have commands specifically to support them, we should
make those commands inform the user -- every user of each of those
commands -- of how they mistreat the user.
It is enough to display a message explaining the situation
in a way that it will really be seen.
Displaying this for the first invocation on each day
would be sufficient. Doing it more often would be annoying.
What you are saying is consistent with the GNU coding standard. However, I think any message about this would be annoying, personally, and would be a deterrent for clients to use this library.
How about this, which I think would satisfy your concerns:
We contribute ONLY llm.el, which mentions no implementations of LLMs, no companies, and no specific language models, to GNU ELPA. With only the interface, I believe there is nothing to warn the user about, and the clients have something in GNU ELPA to code against. If some day there is an LLM that qualifies for inclusion because it is sufficiently free, it can be added to GNU ELPA as well.
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.
If it still seems wrong to you to have an interface in GNU ELPA whose most popular interaces today involves non-free software, then perhaps it might be best to leave this package out of GNU or Non-GNU ELPA for now. I think that would be a shame, since the flexibility it provides is likely the only good hedge against over-reliance on SaaS LLMs, especially in the case that acceptable llms are developed. Such llms are likely available today (research ones come to mind), however I don't have good visibility into that world or the likelihood they would be useful to emacs users.
Would someone please implemt this?
--
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)