emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: master 3d38d1d: Add sqlite3 support to Emacs


From: Alexandre Garreau
Subject: Re: master 3d38d1d: Add sqlite3 support to Emacs
Date: Sun, 12 Dec 2021 06:07:48 +0100

Le dimanĉo, 12-a de decembro 2021, 4-a horo kaj 59:53 CET Richard Stallman 
a écrit :
>                     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.
> 
> Alexandre Garreau <galex-713@galex-713.eu> wrote:
>   > 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.
> 
> Maybe that's not a lot of work.  How many free plug-ins are there?

How is that important? adding a symbol should be atomicly simple.  We 
should automate the making of a patch adding a such definition to any 
library.  Then directly suggest it to distributions such as Debian, as I 
suggested before.  If sqlite people care so little about freedom to 
distribute proprietary plugins, they won’t dare include such symbols, and 
will consider it as esoteric nitpicking, especially when their license is 
“public domain” (which btw isn’t even legal in europe).  But serious 
distributions such as Debian, upon which most of distributions depend, 
would take that seriously.  Other important distributions like RedHat may 
as well.  All other distributions are smaller, and even when they don’t 
really care, such as Arch (but parabola would care), they would follow, as 
soon as not following would break software (and we would make so that it 
would break certain features of emacs).

Btw I’m starting to think that if we’re gonna to push such changes on 
several external plugins to some other software, maybe we should push 
similar changes to gstreamer plugins as well.  To me, it would definitely 
be a cleaner solution to the “don’t load proprietary plugins” as well (and 
would avoid to discriminate against plugins which are free but patent-
encumbered).  We could try to convince GNOME people, and if (or rather 
“once”, imho, since I think they don’t really care about freedom but are 
rather “open source” people), apply the same strategy to their software.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]