On Sat, Aug 12, 2023 at 9:43 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. ]]]
>
>   > 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)
>
>
>