From: Wojtek Kosior via Guix-patches via <guix-patches@gnu.org>
To: Nicolas Goaziou <mail@nicolasgoaziou.fr>
Cc: Andrew Tropin <andrew@trop.in>,
64958@debbugs.gnu.org,
Liliana Marie Prikler <liliana.prikler@gmail.com>,
Cayetano Santos <csantosb@inventati.org>
Subject: [bug#64958] [PATCH] gnu: Add emacs-chatgpt-shell.
Date: Tue, 1 Aug 2023 12:35:22 +0200 [thread overview]
Message-ID: <20230801123522.7f70f5e4.koszko@koszko.org> (raw)
In-Reply-To: <878ravyta5.fsf@nicolasgoaziou.fr>
[-- Attachment #1: Type: text/plain, Size: 3839 bytes --]
> >> Doesn't this package effectively recommend a nonfree
> >> service-as-a-software-substitute? It'd be better to keep users away
> >> from such "services". Also, sorry to say, I'm pretty sure this is
> >> against the Free Software Distribution Guidelines
> > IANAL, but as far as I understand, having clients for various
> > "services" out there, even if those services are not distributed as
> > free software, is permissible.
>
> I also think so. In particular, this is not a SaaSS because there is no
> software to substitute in the first place.
As to centralized services — I also believe it is acceptable to include
clients for them. I mean tools like YouTube video downloaders.
I like how F-Droid approaches this — programs written for the purpose
of connecting to centralized services are labeled as having a possible
anti-feature.
However, I argue that ChatGPT is SaaSS rather than a pure "service".
The software being substituted is a "large language model" (LLM). It
isn't a *conventional* piece of software, it's a trained neural
network. But this doesn't mean it isn't software at all. I performs
advanced computation — that's also what software does.
And since nonfree software shouldn't be recommended in distros, the same
goes with SaaSS.
> I think a clear rule is important, and my opinion is that it should be
> permissive. These clients are useful pieces of software, if only because
> they constitute an opportunity to learn code.
Even if it is a good opportunity, it's a side aspect. Nonfree software
wouldn't get packaged merely because it provides some good opportunity.
So it shouldn't affect the decision here on SaaSS, either.
Also, when looking for some code to take inspiration from, I prefer to
look at public git repositories rather than on distro packages. And
even if I were to learn elisp from Guix packages, there are already
many that do not have freedom issues.
Lastly, I admit this is a harder problem than it seems — search engines
could also be presented as (at least partially) SaaSS and it would be
hard to leave without these
Wojtek
-- (sig_start)
website: https://koszko.org/koszko.html
fingerprint: E972 7060 E3C5 637C 8A4F 4B42 4BC5 221C 5A79 FD1A
follow me on Fediverse: https://friendica.me/profile/koszko/profile
♥ R29kIGlzIHRoZXJlIGFuZCBsb3ZlcyBtZQ== | ÷ c2luIHNlcGFyYXRlZCBtZSBmcm9tIEhpbQ==
✝ YnV0IEplc3VzIGRpZWQgdG8gc2F2ZSBtZQ== | ? U2hhbGwgSSBiZWNvbWUgSGlzIGZyaWVuZD8=
-- (sig_end)
On Tue, 01 Aug 2023 12:02:42 +0200 Nicolas Goaziou <mail@nicolasgoaziou.fr> wrote:
> Hello,
>
> Liliana Marie Prikler <liliana.prikler@gmail.com> writes:
>
> > Am Sonntag, dem 30.07.2023 um 22:51 +0200 schrieb Wojtek Kosior:
> >> Hi!
> >>
> >> > * gnu/packages/emacs-xyz.scm (emacs-chatgpt-shell): New variable.
> >>
> >> Doesn't this package effectively recommend a nonfree
> >> service-as-a-software-substitute? It'd be better to keep users away
> >> from such "services". Also, sorry to say, I'm pretty sure this is
> >> against the Free Software Distribution Guidelines
> > IANAL, but as far as I understand, having clients for various
> > "services" out there, even if those services are not distributed as
> > free software, is permissible.
>
> I also think so. In particular, this is not a SaaSS because there is no
> software to substitute in the first place.
>
> > IMHO, we would need a clear guideline for all of them rather than
> > singling out ChatGPT even if using it is harmful for everyone
> > involved.
> >
> > Nicolas, Andrew, WDYT?
>
> I think a clear rule is important, and my opinion is that it should be
> permissive. These clients are useful pieces of software, if only because
> they constitute an opportunity to learn code.
>
> Regards,
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
next prev parent reply other threads:[~2023-08-01 10:36 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-07-30 15:52 [bug#64958] [PATCH] gnu: Add emacs-chatgpt-shell Cayetano Santos via Guix-patches via
2023-07-30 20:51 ` Wojtek Kosior via Guix-patches via
2023-07-31 7:13 ` Cayetano Santos via Guix-patches via
2023-07-31 20:03 ` Liliana Marie Prikler
2023-08-01 10:02 ` Nicolas Goaziou
2023-08-01 10:35 ` Wojtek Kosior via Guix-patches via [this message]
2023-08-09 9:16 ` Andrew Tropin
2023-09-09 10:31 ` bug#64958: " Liliana Marie Prikler
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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20230801123522.7f70f5e4.koszko@koszko.org \
--to=guix-patches@gnu.org \
--cc=64958@debbugs.gnu.org \
--cc=andrew@trop.in \
--cc=csantosb@inventati.org \
--cc=koszko@koszko.org \
--cc=liliana.prikler@gmail.com \
--cc=mail@nicolasgoaziou.fr \
/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 external index
https://git.savannah.gnu.org/cgit/guix.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.