Re: master 3d38d1d: Add sqlite3 support to Emacs

[Eli Zaretskii <eliz@gnu.org>]

> From: Richard Stallman <rms@gnu.org>
> Cc: eliz@gnu.org, larsi@gnus.org, stefankangas@gmail.com,
> 	emacs-devel@gnu.org
> Date: Sat, 11 Dec 2021 22:59:53 -0500
> 
>                     and provides some details: for instance, should the
>   > symbol be named `plugin_is_GPL_compatible', or something like
>   > `plugin_is_free_software' (as SQLite3 is public domain instead of under
>   > the GPL).
> 
> I don't know anything technically about sqlite3, so I can't begin
> to think about how to implement this, and I'm not sure what your
> suggestions really mean.
> 
> What I do know is this: the crucial question is not what name that
> symbol should have, but rather, Which programs need to define it?
> Are you proposing to modify the free plug-ins to define this symbol,
> and make sqlite3 itself check for it?
> 
> We really should have addressed this _before_ putting sqlite3 into the
> Emacs repository at all.

The issue of loading extensions is somewhat orthogonal to sqlite3
support itself.  Loading of sqlite3 extensions requires an explicit
call to an Emacs primitive, it cannot happen automatically.

>   > It should reuse what gcc does to load its plugins.  GCC asks for a such 
>   > symbol to check the plugins are GPLv3-compatible.
> 
> That's a good thing to do, but note that every plugin for GCC was
> written specifically for dynamic linking with GCC.  The plugin's
> developers define ths symbols to be checked.
> 
> If we put the same mechanism into a modified sqlite3 -- let's call it
> "GNUish sqlite3" -- we will need to make GNUish modified versions of
> the plug-ins as well.

No, the idea is that Emacs itself will verify the compatibility before
asking sqlite3 to load the extension.