Re: [NonGNU ELPA] New package: llm

[Ihor Radchenko]

Richard Stallman <rms@gnu.org> writes:

> Could you please tell me what conclusions or ideas that discussion
> reached?

Among other things, we have discussed Oracle SQL support in sql.el:

https://list.orgmode.org/orgmode/E1pKtph-00082q-4Z@fencepost.gnu.org/
Richard Stallman <rms@gnu.org> writes:

> ...
>   > The 'support' is essentially specialised comint based interfaces tweaked
>   > to work with the various SQL database engine command line clients such
>   > as psql for Postgres and sqlplus for Oracle. This involves codes to use
>   > the comint buffer to send commands/regions to the SQL client and read
>   > back the results and run interactive 'repl' like sessions with the
>   > client.
>
> Thanks.
>
> Based on our general policies, it is ok to do this.  It is ok for
> Postgres because that is free software.  It is ok for Oracle because
> that is widely known.

Another relevant bit is related to the fact the Oracle SQL, through its
free CLI, may actually connect to SaaS server.

https://list.orgmode.org/orgmode/E1pKtpq-00086w-9s@fencepost.gnu.org/
Richard Stallman <rms@gnu.org> writes:

> ...
>   > I am not sure about SaaSS - even postgresql (free software) may be used
>   > as a service provider by running it on server the user does not control.
>
> For sure, it CAN be used that way.  If a Lisp package is designed to
> work with a subprocess, a user can certainly rig it to talk with a
> remote server.  It is the nature of free software that people can
> customize it, even so as to do something foolish with it.  When a user
> does this, it's per responsibility, not ours.
>
> We should not distribute specific support or recommendations to use
> the Lisp package in that particular way.

I also suggested the following, although did not yet find time open
discussion on emacs-devel:

https://list.orgmode.org/orgmode/87k015e80p.fsf@localhost/
Ihor Radchenko <yantar92@posteo.net> writes:

> Richard Stallman <rms@gnu.org> writes:
>
>>   > Would it then make sense to note the reasons why we support one or
>>   > another non-free software in a separate file like etc/NON-FREE-SUPPORT?
>>
>> I think it is a good idea to document the reasoning for these
>> decision.  But I think it does not necessarily have to be centralized
>> in one file for all of Emacs.  Another alternative, also natural,
>> would be to describe these decisions with the code that implements the
>> support.
>
> Will file header be a good place?
>
> Note that there is little point adding the reasons behind supporting
> non-free software if they cannot be easily found. Ideally, it should be
> a standard place documented as code convention. Then, people can
> consistently check the reasons (or lack of) behind each individual
> non-free software support decision.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>