On Sun, Aug 27, 2023 at 2:36 PM Jim Porter <jporterbugs@gmail.com> wrote:
On 8/26/2023 6:07 PM, Andrew Hyatt wrote:
> To save you the trouble of looking at the code to see what exactly it
> says, here's the function I'm using to warn:
>
> (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)))

To make this easier on third parties writing their own implementations
for other LLMs, maybe you could make this (mostly) automatic? I see that
you're using 'cl-defgeneric' in the code, so what about something like this?

   (cl-defgeneric llm-free-p (provider)
     "Return non-nil if PROVIDER is a freedom-respecting model."
     nil)

   (cl-defmethod llm-free-p ((provider my-free-llm))
     t)

Then, if all user-facing functions have some implementation that always
calls this (maybe using the ":before" key for the generic functions?),
third parties won't forget to set up the warning code; instead, they'll
need to explicitly mark their LLM provider as free.

Good idea.  I implemented something close to what you suggest, but I had to make a few changes to get it to be workable.
Thank you for the suggestion!
 
I also see that there's a defcustom ('llm-warn-on-nonfree') that lets
people opt out of this. I think it's a good idea to give users that
control, but should this follow a similar pattern to
'inhibit-startup-echo-area-message'? Its docstring says:

> The startup message is in the echo area as it provides information
> about GNU Emacs and the GNU system in general, which we want all
> users to see.  As this is the least intrusive startup message,
> this variable gets specialized treatment to prevent the message
> from being disabled site-wide by systems administrators, while
> still allowing individual users to do so.
>
> Setting this variable takes effect only if you do it with the
> customization buffer or if your init file contains a line of this
> form:
>  (setq inhibit-startup-echo-area-message "YOUR-USER-NAME")

If we want it to be easy for users to opt out of the message, but hard
for admins (or other packages) to automate opting out, something like
the above might make sense.

Very interesting, thanks.  I took a look at the implementation, and I'd prefer not to do anything like that (which involves looking through the user's init file, and seems like it would miss at least some cases).  For now, I'll keep it simple.