emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [NonGNU ELPA] New package: llm


From: Andrew Hyatt
Subject: Re: [NonGNU ELPA] New package: llm
Date: Sun, 27 Aug 2023 22:32:28 -0400

On Sun, Aug 27, 2023 at 9:32 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. ]]]

  > > (defun llm--warn-on-nonfree (name tos)
  > >   "Issue a warning if `llm-warn-on-nonfree' is non-nil.
  > > NAME is the human readable name of the LLM (e.g 'Open AI').
  > >
  > > TOS is the URL of the terms of service for the LLM.
  > >
  > > All non-free LLMs should call this function on each llm function
  > > invocation."
  > >   (when llm-warn-on-nonfree
  > >     (lwarn '(llm nonfree) :warning "%s API is not free software, and your
  > > freedom to use it is restricted.
  > > See %s for the details on the restrictions on use." name tos)))

I presume that the developers judge whether any given LLM calls for a
warning, and add a call to this function if it does.  Right?

The basic approach looks right, bit it raises two questions about
details:

1. What exactly is the criterion for deciding whether a given LLM
should call this function?  In other words, what are the conditions on
which we should warn the user?  Let's discuss that to make sure we
get it right.

After following Jim Porter's suggestion above, here is the new function, and you can see the advice we're giving in the docstring:

(cl-defgeneric llm-nonfree-message-info (provider)
  "If PROVIDER is non-free, return info for a warning.
This should be a cons of the name of the LLM, and the URL of the
terms of service.

If the LLM is free and has no restrictions on use, this should
return nil. Since this function already returns nil, there is no
need to override it."
  (ignore provider)
  nil)

So, "free and no restrictions on use".  I'm happy to link to any resources to help users understand better if you think it is needed.
 

2. Is it better to include the TSO URL in the warning, or better NOT
to include it and thus avoid helping bad guys publicize their demands?

I think it's best to include it.  To claim there are restrictions on use, but not reference those same restrictions strikes me as incomplete, from the point of view of the user who will be looking at the warning.
 
 

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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]