unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Andrew Hyatt <ahyatt@gmail.com>
To: Jim Porter <jporterbugs@gmail.com>
Cc: rms@gnu.org, Philip Kaludercic <philipk@posteo.net>, emacs-devel@gnu.org
Subject: Re: [NonGNU ELPA] New package: llm
Date: Mon, 28 Aug 2023 00:54:49 -0400	[thread overview]
Message-ID: <CAM6wYYLJvkuHadw5Kyd_vgdAzndVt4n1YDx8FUv9OQ6v2gZ7vQ@mail.gmail.com> (raw)
In-Reply-To: <fd98dcaf-5016-1a84-f281-36ef6eb108c5@gmail.com>

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

On Sun, Aug 27, 2023 at 10:59 PM Jim Porter <jporterbugs@gmail.com> wrote:

> On 8/27/2023 7:32 PM, Andrew Hyatt wrote:
> > 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)
>
> For what it's worth, I was thinking about having the default be the
> opposite: warn users by default, since we don't really know if an LLM
> provider is free unless the Elisp code indicates it. (Otherwise, it
> could simply mean the author of that provider forgot to override
> 'llm-nonfree-message-info'.) In other words, assume the worst by
> default. :) That said, if everyone else thinks this isn't an issue, I
> won't stamp my feet about it.
>

I agree that it'd be nice to have that property.  That's the way I had it
initially, but since you need info if it's non-free (the name / TOS), but
not if it is free, the design where free was the default was the simplest.
The alternative was one method indicating it was free/nonfree and the
other, if non-free, to provide the additional information.


>
> As for the docstring, I see that many models use ordinary software
> licenses, such as the Apache license. That could make it easier for us
> to define the criteria for a libre provider: is the model used by the
> provider available under a license the FSF considers a free software
> license?[1] (For LLM providers that you use by making a web request, we
> could also expect that all the code for their web API is libre too.
> However, that code is comparatively uninteresting, and so long as you
> could get the model to use on a self-hosted system[2], I don't see a
> need to warn the user.)
>

I agree that it'd be nice to define this in a more clear way, but we also
can just wait until someone proposes a free LLM to include to judge it.  We
can always bring it back to the emacs-devel list if there is uncertainty.

The hosting code is not that relevant here.  For these companies, there
would be restrictions on the use of the model even if there were no other
unfree software in the middle (kind of like how Llama 2 is).  Notably, no
company is going to want the user to train competing models with their
model.   This is the most common restriction on freedoms of the user.


>
> (Also, if you prefer to avoid having to say '(ignore provider)', you can
> also prefix 'provider' with an underscore. That'll make the byte
> compiler happy.)
>

TIL, that's a great tip, thanks!


>
> [1] https://www.gnu.org/licenses/license-list.en.html
>
> [2] At least, in theory. A user might not have enough computing power to
> use the model in practice, but I don't think that matters for this case.
>

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

  reply	other threads:[~2023-08-28  4:54 UTC|newest]

Thread overview: 55+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-08-07 23:54 [NonGNU ELPA] New package: llm Andrew Hyatt
2023-08-08  5:42 ` Philip Kaludercic
2023-08-08 15:08   ` Spencer Baugh
2023-08-08 15:09   ` Andrew Hyatt
2023-08-09  3:47 ` Richard Stallman
2023-08-09  4:37   ` Andrew Hyatt
2023-08-13  1:43     ` Richard Stallman
2023-08-13  1:43     ` Richard Stallman
2023-08-13  2:11       ` Emanuel Berg
2023-08-15  5:14       ` Andrew Hyatt
2023-08-15 17:12         ` Jim Porter
2023-08-17  2:02           ` Richard Stallman
2023-08-17  2:48             ` Andrew Hyatt
2023-08-19  1:51               ` Richard Stallman
2023-08-19  9:08                 ` Ihor Radchenko
2023-08-21  1:12                   ` Richard Stallman
2023-08-21  8:26                     ` Ihor Radchenko
2023-08-17 17:08             ` Daniel Fleischer
2023-08-19  1:49               ` Richard Stallman
2023-08-19  8:15                 ` Daniel Fleischer
2023-08-21  1:12                   ` Richard Stallman
2023-08-21  4:48               ` Jim Porter
2023-08-21  5:12                 ` Andrew Hyatt
2023-08-21  6:03                   ` Jim Porter
2023-08-21  6:36                 ` Daniel Fleischer
2023-08-22  1:06                 ` Richard Stallman
2023-08-16  2:30         ` Richard Stallman
2023-08-16  5:11           ` Tomas Hlavaty
2023-08-18  2:10             ` Richard Stallman
2023-08-27  1:07       ` Andrew Hyatt
2023-08-27 13:11         ` Philip Kaludercic
2023-08-28  1:31           ` Richard Stallman
2023-08-28  2:32             ` Andrew Hyatt
2023-08-28  2:59               ` Jim Porter
2023-08-28  4:54                 ` Andrew Hyatt [this message]
2023-08-31  2:10                 ` Richard Stallman
2023-08-31  9:06                   ` Ihor Radchenko
2023-09-04  1:27                     ` Richard Stallman
2023-09-06 12:25                       ` Ihor Radchenko
2023-09-04  1:27                     ` Richard Stallman
2023-08-27 18:36         ` Jim Porter
2023-08-28  0:19           ` Andrew Hyatt
2023-09-04  1:27           ` Richard Stallman
2023-09-04  5:18             ` Andrew Hyatt
2023-09-07  1:21               ` Richard Stallman
2023-09-12  4:54                 ` Andrew Hyatt
2023-09-12  9:57                   ` Philip Kaludercic
2023-09-12 15:05                   ` Stefan Kangas
2023-09-19 16:26                     ` Andrew Hyatt
2023-09-19 16:34                       ` Philip Kaludercic
2023-09-19 18:19                         ` Andrew Hyatt
2023-09-04  1:27         ` Richard Stallman
2023-08-09  3:47 ` Richard Stallman
2023-08-09  4:06   ` Andrew Hyatt
2023-08-12  2:44     ` Richard Stallman

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAM6wYYLJvkuHadw5Kyd_vgdAzndVt4n1YDx8FUv9OQ6v2gZ7vQ@mail.gmail.com \
    --to=ahyatt@gmail.com \
    --cc=emacs-devel@gnu.org \
    --cc=jporterbugs@gmail.com \
    --cc=philipk@posteo.net \
    --cc=rms@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).