Re: [NonGNU ELPA] New package: llm

[Andrew Hyatt <ahyatt@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 3220 bytes --]

On Tue, Aug 8, 2023 at 11:47 PM Richard Stallman <rms@gnu.org> wrote:

> [[[ 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)
>
>
>

[-- Attachment #2: Type: text/html, Size: 4358 bytes --]