Re: master 3d38d1d: Add sqlite3 support to Emacs

Re: master 3d38d1d: Add sqlite3 support to Emacs

[Stefan Kangas]

larsi@gnus.org (Lars Ingebrigtsen) writes:

> branch: master
> commit 3d38d1d1345aa65c4018b42e6c648606e32216f8
> Author: Lars Ingebrigtsen <larsi@gnus.org>
> Commit: Lars Ingebrigtsen <larsi@gnus.org>
>
>     Add sqlite3 support to Emacs

Great, thank you.  Some minor nits below:

> diff --git a/lisp/sqlite.el b/lisp/sqlite.el
> new file mode 100644
> index 0000000..a47689c
> --- /dev/null
> +++ b/lisp/sqlite.el
> @@ -0,0 +1,42 @@
> +;;; sqlite.el --- Tests for empty.el  -*- lexical-binding: t; -*-

Is that file header correct?

> +This file is based on the emacs-sqlite3 package written by Syohei
> +YOSHIDA <syohex@gmail.com>, which can be found at:
> +
> +   https://github.com/syohex/emacs-sqlite3

Consider adding here: "Integrated into Emacs by Lars Ingebrigtsen."

> +DEFUN ("sqlite-load-extension", Fsqlite_load_extension,
> +       Ssqlite_load_extension, 2, 2, 0,
> +       doc: /* Load a an SQlite module into DB.
                       ^^^^

"an"

> +DEFUN ("sqlite-more-p", Fsqlite_more_p, Ssqlite_more_p, 1, 1, 0,
> +       doc: /* Say whether there's any further results in SET.  */)
                              ^^^^^^^

Should that be "there are"?

> +;;; sqlite-tests.el --- Tests for sqlite.el  -*- lexical-binding: t; -*-
[snip]
> +;; (setq db (sqlite-open))

Left-over debug statement?

Re: master 3d38d1d: Add sqlite3 support to Emacs

[Po Lu]

Stefan Kangas <stefankangas@gmail.com> writes:

> larsi@gnus.org (Lars Ingebrigtsen) writes:
>
>> branch: master
>> commit 3d38d1d1345aa65c4018b42e6c648606e32216f8
>> Author: Lars Ingebrigtsen <larsi@gnus.org>
>> Commit: Lars Ingebrigtsen <larsi@gnus.org>
>>
>>     Add sqlite3 support to Emacs

BTW, this doesn't compile on macOS.  It complains that
`sqlite3_load_extension' is missing.

Also, shouldn't configure say something to the likes of "Does Emacs have
SQLite support?" and also add SQLITE to system-configuration-features?

Thanks.

Re: master 3d38d1d: Add sqlite3 support to Emacs

[Lars Ingebrigtsen]

Stefan Kangas <stefankangas@gmail.com> writes:

> Great, thank you.  Some minor nits below:

Fixed now.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: master 3d38d1d: Add sqlite3 support to Emacs

[Lars Ingebrigtsen]

Po Lu <luangruo@yahoo.com> writes:

> BTW, this doesn't compile on macOS.  It complains that
> `sqlite3_load_extension' is missing.

It compiles for me on Macos, but perhaps that function is missing in
your version of sqlite?  What's your version?

> Also, shouldn't configure say something to the likes of "Does Emacs have
> SQLite support?" and also add SQLITE to system-configuration-features?

It says that for me:

  Does Emacs use -lsqlite3?                               yes


-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: master 3d38d1d: Add sqlite3 support to Emacs

[Po Lu]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Po Lu <luangruo@yahoo.com> writes:
>
>> BTW, this doesn't compile on macOS.  It complains that
>> `sqlite3_load_extension' is missing.
>
> It compiles for me on Macos, but perhaps that function is missing in
> your version of sqlite?  What's your version?

It's 3.36.0.  The headers were installed with `xcode-select --install'.

> It says that for me:
>
>   Does Emacs use -lsqlite3?                               yes

Hmm, okay.

Re: master 3d38d1d: Add sqlite3 support to Emacs

[Po Lu]

Po Lu <luangruo@yahoo.com> writes:

> BTW, this doesn't compile on macOS.  It complains that
> `sqlite3_load_extension' is missing.

On a different note, SQLite3 extensions are linked dynamically, and they
could be proprietary software.  AFAIU, the SQLite3 developers even
provide a few proprietary extensions themselves, including one for
database encryption.

So I think we should check that the .so file passed to
`sqlite-load-extension' as the `module' argument contains a GPL
compatibility symbol before allowing SQLite to load it, similar to what
we do with Emacs modules.

RMS or someone else in the FSF might want to make sure loading SQLite
modules is okay from a legal perspective as well.  I don't know the
details, but we had legal problems with some SQLite modules at my
organization.

Hope this helped, thanks.

Re: master 3d38d1d: Add sqlite3 support to Emacs

[Lars Ingebrigtsen]

Po Lu <luangruo@yahoo.com> writes:

> It's 3.36.0.  The headers were installed with `xcode-select --install'.

Hm, same version that's on this Debian/bookworm...  perhaps Apple's just
remove the option to lock things down more?

In any case, I've now added more checks to configure.ac for that function.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: master 3d38d1d: Add sqlite3 support to Emacs

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: Lars Ingebrigtsen <larsi@gnus.org>,  emacs-devel@gnu.org, rms@gnu.org
> Date: Sat, 11 Dec 2021 15:04:35 +0800
> 
> Po Lu <luangruo@yahoo.com> writes:
> 
> > BTW, this doesn't compile on macOS.  It complains that
> > `sqlite3_load_extension' is missing.
> 
> On a different note, SQLite3 extensions are linked dynamically, and they
> could be proprietary software.  AFAIU, the SQLite3 developers even
> provide a few proprietary extensions themselves, including one for
> database encryption.
> 
> So I think we should check that the .so file passed to
> `sqlite-load-extension' as the `module' argument contains a GPL
> compatibility symbol before allowing SQLite to load it, similar to what
> we do with Emacs modules.

Would you like to prepare a patch to that effect, please?

Re: master 3d38d1d: Add sqlite3 support to Emacs

[Po Lu]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Po Lu <luangruo@yahoo.com>
>> Cc: Lars Ingebrigtsen <larsi@gnus.org>,  emacs-devel@gnu.org, rms@gnu.org
>> Date: Sat, 11 Dec 2021 15:04:35 +0800
>> 
>> Po Lu <luangruo@yahoo.com> writes:
>> 
>> > BTW, this doesn't compile on macOS.  It complains that
>> > `sqlite3_load_extension' is missing.
>> 
>> On a different note, SQLite3 extensions are linked dynamically, and they
>> could be proprietary software.  AFAIU, the SQLite3 developers even
>> provide a few proprietary extensions themselves, including one for
>> database encryption.
>> 
>> So I think we should check that the .so file passed to
>> `sqlite-load-extension' as the `module' argument contains a GPL
>> compatibility symbol before allowing SQLite to load it, similar to what
>> we do with Emacs modules.

> Would you like to prepare a patch to that effect, please?

I would be willing to, but only if someone from a higher authority says
it's necessary, 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).

Thanks.

Re: master 3d38d1d: Add sqlite3 support to Emacs

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: larsi@gnus.org,  stefankangas@gmail.com,  rms@gnu.org,  emacs-devel@gnu.org
> Date: Sat, 11 Dec 2021 17:20:44 +0800
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> So I think we should check that the .so file passed to
> >> `sqlite-load-extension' as the `module' argument contains a GPL
> >> compatibility symbol before allowing SQLite to load it, similar to what
> >> we do with Emacs modules.
> 
> > Would you like to prepare a patch to that effect, please?
> 
> I would be willing to, but only if someone from a higher authority says
> it's necessary, 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).

OK, let's wait for Richard to chime in on this aspect.

Thanks.

Re: master 3d38d1d: Add sqlite3 support to Emacs

[Alexandre Garreau]

Le sabato, 11-a de decembro 2021, 10-a horo kaj 20:44 CET Po Lu a écrit :
> 
> 
> > Would you like to prepare a patch to that effect, please?
> 
> I would be willing to, but only if someone from a higher authority says
> it's necessary, 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).

It should reuse what gcc does to load its plugins.  GCC asks for a such 
symbol to check the plugins are GPLv3-compatible.

Re: master 3d38d1d: Add sqlite3 support to Emacs

[Po Lu]

Alexandre Garreau <galex-713@galex-713.eu> writes:

> Le sabato, 11-a de decembro 2021, 10-a horo kaj 20:44 CET Po Lu a écrit :
>> 
>> 
>> > Would you like to prepare a patch to that effect, please?
>> 
>> I would be willing to, but only if someone from a higher authority says
>> it's necessary, 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).

> It should reuse what gcc does to load its plugins.  GCC asks for a such 
> symbol to check the plugins are GPLv3-compatible.

That is because GCC is licensed under the GPLv3.  Ditto for Emacs, which
checks for the same symbol before loading a dynamic module.

The question here is what to do with SQLite plugins, which are specific
to SQLite and not Emacs, and are not legally required to be
GPLv3-compatible.

Re: master 3d38d1d: Add sqlite3 support to Emacs

[Alexandre Garreau]

Le sabato, 11-a de decembro 2021, 13-a horo kaj 49:36 CET Po Lu a écrit :
> 
> 
> > It should reuse what gcc does to load its plugins.  GCC asks for a
> > such
> > symbol to check the plugins are GPLv3-compatible.
> 
> That is because GCC is licensed under the GPLv3.  Ditto for Emacs, which
> checks for the same symbol before loading a dynamic module.
> 
> The question here is what to do with SQLite plugins, which are specific
> to SQLite and not Emacs, and are not legally required to be
> GPLv3-compatible.

Shouldn’t we hack both sqlite and its module to integrate just the same 
symbol?

If ever sqlite people disagree (if they write proprietary software, 
they’re likely not that librists, hence maybe anti-copyleft), we could 
convince distributions to force that change instead.  Most distributions 
patch software.  Debian would be a first candidate (and would cascade effect 
on many of its derivatives).  It would just as well be in the interest of 
RedHat.  Arch and Gentoo are usually less enthusiasts about such issues, 
but they’re versatile and if bigger distributions start doing it, and 
doing otherwise breaks software, they’ll end up changing that too.

Plus it doesn’t seem to be a very complex change, hence maintaining a 
single patch for that shouldn’t be that difficult over time.

Re: master 3d38d1d: Add sqlite3 support to Emacs

[Po Lu]

Alexandre Garreau <galex-713@galex-713.eu> writes:

> Shouldn’t we hack both sqlite and its module to integrate just the same 
> symbol?

I don't understand what you're asking.  I was asking whether or not
`plugin_is_GPL_compatible' is the appropriate name for a symbol we will
use to determine if a SQLite plugin is suitable for use inside Emacs.

We don't need to patch SQLite to look for such a symbol inside a plugin,
but I don't know what name would be appropriate for it.

Thanks.

Re: master 3d38d1d: Add sqlite3 support to Emacs

[Alexandre Garreau]

Le sabato, 11-a de decembro 2021, 14-a horo kaj 29:41 CET Po Lu a écrit :
> Alexandre Garreau <galex-713@galex-713.eu> writes:
> 
> 
> 
> > Shouldn’t we hack both sqlite and its module to integrate just the
> > same
> > symbol?
> 
> I don't understand what you're asking.  I was asking whether or not
> `plugin_is_GPL_compatible' is the appropriate name for a symbol we will
> use to determine if a SQLite plugin is suitable for use inside Emacs.
> 
> We don't need to patch SQLite to look for such a symbol inside a plugin,
> but I don't know what name would be appropriate for it.

well what’s the name for the symbol used by gcc for that same usage? I 
already asked that…

…wait it is indeed plugin_is_GPL_compatible, so why not using that? that’s 
precisely what I suggested to do.

Why wouldn’t such hacking be needed? as of now both sqlite and its plugins 
don’t include such a symbol, right?

Re: master 3d38d1d: Add sqlite3 support to Emacs

[Eli Zaretskii]

> From: Alexandre Garreau <galex-713@galex-713.eu>
> Date: Sat, 11 Dec 2021 13:57:55 +0100
> 
> Shouldn’t we hack both sqlite and its module to integrate just the same 
> symbol?

No, we won't be making local changes in the sqlite3 library.  That way
lies madness.

Re: master 3d38d1d: Add sqlite3 support to Emacs

[Alexandre Garreau]

Le sabato, 11-a de decembro 2021, 14-a horo kaj 51:17 CET Eli Zaretskii a 
écrit :
> > From: Alexandre Garreau <galex-713@galex-713.eu>
> > Date: Sat, 11 Dec 2021 13:57:55 +0100
> > 
> > Shouldn’t we hack both sqlite and its module to integrate just the
> > same
> > symbol?
> 
> No, we won't be making local changes in the sqlite3 library.  That way
> lies madness.

so how do we check license?

Re: master 3d38d1d: Add sqlite3 support to Emacs

[Stefan Monnier]

> I would be willing to, but only if someone from a higher authority says
> it's necessary, 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).

Intuitively, I think `plugin_is_GPL_compatible` is right: when sqlite is
linked with Emacs, the whole becomes GPLv3+, so in order for sqlite's
plugins to be compatible with that they too need to be compatible with
GPLv3+.


        Stefan

Re: master 3d38d1d: Add sqlite3 support to Emacs

[Eli Zaretskii]

> From: Alexandre Garreau <galex-713@galex-713.eu>
> Date: Sat, 11 Dec 2021 14:55:00 +0100
> 
> Le sabato, 11-a de decembro 2021, 14-a horo kaj 51:17 CET Eli Zaretskii a 
> écrit :
> > > From: Alexandre Garreau <galex-713@galex-713.eu>
> > > Date: Sat, 11 Dec 2021 13:57:55 +0100
> > > 
> > > Shouldn’t we hack both sqlite and its module to integrate just the
> > > same
> > > symbol?
> > 
> > No, we won't be making local changes in the sqlite3 library.  That way
> > lies madness.
> 
> so how do we check license?

We are still discussing this, stay tuned.

Re: master 3d38d1d: Add sqlite3 support to Emacs

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > >> So I think we should check that the .so file passed to
  > >> `sqlite-load-extension' as the `module' argument contains a GPL
  > >> compatibility symbol before allowing SQLite to load it, similar to what
  > >> we do with Emacs modules.

  > > Would you like to prepare a patch to that effect, please?

  > I would be willing to, but only if someone from a higher authority says
  > it's necessary,

It's absolutely necessary.  Emacs should not be a base for nonfree
extensions.

                    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?

  > The question here is what to do with SQLite plugins, which are specific
  > to SQLite and not Emacs, and are not legally required to be
  > GPLv3-compatible.

Can we make Emacs load the plug-in, and check for the symbol,
then arrange for sqlite3 to talk with it?

We would need to prevent sqlite3 from loading plug-ins itself.
But I think that all designs require some sort of change to
sqlite3, because what it's designed to do is not acceptable as it stands.
I see no way around the need to change sqlite3.

Stefan Monnier wrote:

  > Intuitively, I think `plugin_is_GPL_compatible` is right: when sqlite is
  > linked with Emacs, the whole becomes GPLv3+, so in order for sqlite's
  > plugins to be compatible with that they too need to be compatible with
  > GPLv3+.

I think you're right.  That seems to settle the question of what name to use.
But we still have to deal with how to design this code to work.

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: master 3d38d1d: Add sqlite3 support to Emacs

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > RMS or someone else in the FSF might want to make sure loading SQLite
  > modules is okay from a legal perspective as well.  I don't know the
  > details, but we had legal problems with some SQLite modules at my
  > organization.

If I ask a very broad question, a lawyer would have no idea what the
issue is, and could not answer.  Can you inquire what sort of legal
issue the plug-ins raised, and tell me privately?

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: master 3d38d1d: Add sqlite3 support to Emacs

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > So I think we should check that the .so file passed to
  > `sqlite-load-extension' as the `module' argument contains a GPL

What is `sqlite-load-extension', and what does it do?
What are its arguments, and what do they mean?
I have no information about this.

Could you please send me the specifications of these functions?
Of this interface?

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: master 3d38d1d: Add sqlite3 support to Emacs

[Po Lu]

Richard Stallman <rms@gnu.org> writes:

> 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.

Basically, SQLite has the ability to load extensions (in the form of
shared libraries) at runtime.  But it doesn't provide a mechanism to let
programs determine whether an extension is acceptable before loading it.

Even worse, SQLite is under the public domain and not the GPL, so it is
legally permissible to create proprietary extensions.  The developers of
SQLite also maintain proprietary extensions for database compression and
encryption, both of which can be loaded through the mechanism currently
present in Emacs.

For more technical details, you can look at the following web page:
https://www.sqlite.org/loadext.html.  It should work from any browser
without JavaScript.

> 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?

No, I'm proposing to modify the free plug-ins to define this symbol, and
then to make Emacs to check for it before telling SQLite to load the
plugin.  It would work the same, and it'd also be much easier than
modifying SQLite and having to maintain the modified version, and so on
and so forth.

> Can we make Emacs load the plug-in, and check for the symbol,
> then arrange for sqlite3 to talk with it?

That's not possible, but we can check the .so file of the plugin for
such a symbol before telling SQLite3 to load it.

> We would need to prevent sqlite3 from loading plug-ins itself.
> But I think that all designs require some sort of change to
> sqlite3, because what it's designed to do is not acceptable as it stands.
> I see no way around the need to change sqlite3.

We could also remove the ability to load SQLite extensions from Emacs.

Thanks.

Re: master 3d38d1d: Add sqlite3 support to Emacs

[Po Lu]

Richard Stallman <rms@gnu.org> writes:

> What is `sqlite-load-extension', and what does it do?  What are its
> arguments, and what do they mean?  I have no information about this.

> Could you please send me the specifications of these functions?
> Of this interface?

`sqlite-load-extension' takes two arguments `db' and `module'.  DB is an
SQLite database that the module will be loaded into, and `module' is a
path to the shared library that comprises the extension.

I explained what such an extension is in my other reply to you.

Thanks.

Re: master 3d38d1d: Add sqlite3 support to Emacs

[Alexandre Garreau]

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.

Re: master 3d38d1d: Add sqlite3 support to Emacs

[Po Lu]

Alexandre Garreau <galex-713@galex-713.eu> writes:

> 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.

GStreamer is not developed by GNOME people, who as part of the GNU
project will likely care more about this.  It is developed by
Freedesktop.

Re: master 3d38d1d: Add sqlite3 support to Emacs

[Alexandre Garreau]

Le dimanĉo, 12-a de decembro 2021, 6-a horo kaj 17:36 CET Po Lu a écrit :
> Alexandre Garreau <galex-713@galex-713.eu> writes:
> 
> 
> 
> > 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.
> 
> GStreamer is not developed by GNOME people, who as part of the GNU
> project will likely care more about this. 

It may be true historically but politically GNOME people (especially GNOME 
foundation) don’t consider themselves part of GNU anymore, and they often 
talk about “open source” or “cloud” as positive things on themselves, and 
talk little about freedom.

> It is developed by
> Freedesktop.

What does the G stand for then?

Re: master 3d38d1d: Add sqlite3 support to Emacs

[Eli Zaretskii]

> 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.

Re: master 3d38d1d: Add sqlite3 support to Emacs

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > No, I'm proposing to modify the free plug-ins to define this symbol, and
  > then to make Emacs to check for it before telling SQLite to load the
  > plugin.  It would work the same, and it'd also be much easier than
  > modifying SQLite and having to maintain the modified version, and so on
  > and so forth.

I don't think that is legally adequate.  I have an idea for a solution
to that problem, but I need to check it with a lawyer first.

For the mean time, Emacs _should not_ offer any interface to load
sqlite3 extensions.

But eliminating that is _not_ enough to solve the problem, because
sqlite3 offers another way to load one!  It defines an SQL function,
load_extension, to load an extension.  Whatever testing that Emacs
would try to do on an extension before loading it, load_extension
would bypass it.

Is there a way we can undefine that SQL function?  The equivalent of
fmakunbound in Lisp?

Is there a way Emacs can delete that function from the SQL function
table before the user can run any SQL code?

Does SQL have a way undefine a function?  If so, Emacs could run the
SQL to undefine that function, before it lets the user run any SQL
code.

Not as nice, because less modular: Emacs could patch the SQL function
table "by hand" to remove that definition.

We could patch the code in sqlite3 that loads extensions to make it
call a hook, and ask the developers to include it so that we can
use the standard version of sqlite3.  For the mean time, we would
need to use the patched version.

The clean way to do this is to add a C function to sqlite3 which you
call with a pointer to your hook function.  That would be an upward
compatible change to sqlite3, thus no trouble for upstream.

Since Emacs will call this C function, this will prevent simply
linking Emacs with the unmodified sqlite3.

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: master 3d38d1d: Add sqlite3 support to Emacs

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > 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.

The Gstreamer case and the sqlite3 case are structurally analogous,
but I think they are very different in practice.  Correct me if I'm wrong,
but my understanding is that EVERY use of Gstreamer requires plug-ins,
but hardly any user of sqlite3 uses plug-ins.

If I am right about that, it would be adequate, for sqlite3, to
prevent loading plug-ins at all, but doing that for Gstreamer would
make it useless.

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: master 3d38d1d: Add sqlite3 support to Emacs

[Lars Ingebrigtsen]

Richard Stallman <rms@gnu.org> writes:

> But eliminating that is _not_ enough to solve the problem, because
> sqlite3 offers another way to load one!  It defines an SQL function,
> load_extension, to load an extension.

That SQL function is only available if it has been enabled on the C
level.  We don't do that, so it's irrelevant.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: master 3d38d1d: Add sqlite3 support to Emacs

[Po Lu]

Richard Stallman <rms@gnu.org> writes:

> The Gstreamer case and the sqlite3 case are structurally analogous,
> but I think they are very different in practice.  Correct me if I'm wrong,
> but my understanding is that EVERY use of Gstreamer requires plug-ins,
> but hardly any user of sqlite3 uses plug-ins.
>
> If I am right about that, it would be adequate, for sqlite3, to
> prevent loading plug-ins at all, but doing that for Gstreamer would
> make it useless.

Your understanding is correct.  Lars, I think it would be appropriate to
remove the Lisp function for loading SQLite extensions for the time
being.

Re: master 3d38d1d: Add sqlite3 support to Emacs

[Lars Ingebrigtsen]

Po Lu <luangruo@yahoo.com> writes:

> Your understanding is correct.  Lars, I think it would be appropriate to
> remove the Lisp function for loading SQLite extensions for the time
> being.

We're still exploring options.  It's a long time 'til Emacs 29.

One simple possibility would be to have a whitelist of useful (and free)
sqlite plugins.  I doubt it'd be very long.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: master 3d38d1d: Add sqlite3 support to Emacs

[Po Lu]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> One simple possibility would be to have a whitelist of useful (and
> free) sqlite plugins.  I doubt it'd be very long.

How would that work?  Not many SQLite plugin binaries are reproducible,
and unlike GStreamer their names do not have any special meaning.

Thanks.

Re: master 3d38d1d: Add sqlite3 support to Emacs

[Lars Ingebrigtsen]

Po Lu <luangruo@yahoo.com> writes:

>> One simple possibility would be to have a whitelist of useful (and
>> free) sqlite plugins.  I doubt it'd be very long.
>
> How would that work?  Not many SQLite plugin binaries are reproducible,
> and unlike GStreamer their names do not have any special meaning.

Just a list of names.  There is, after all, no actual technical way to
stop anybody from loading whatever they want into the Emacs binary, from
playing games with LD_PRELOAD to rebuilding Emacs.  All the "technical"
things we do (checksumming, checking for symbols with GPL in them) are
just a way of saying "we'd rather not cater to this use case".

But users are welcome to do whatever they want to, of course.  It's free
software.  (And we couldn't stop them even if we wanted to, fortunately.)

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: master 3d38d1d: Add sqlite3 support to Emacs

[Andy Moreton]

On Sun 12 Dec 2021, Richard Stallman wrote:

> [[[ To any NSA and FBI agents reading my email: please consider    ]]]
> [[[ whether defending the US Constitution against all enemies,     ]]]
> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
>
>   > No, I'm proposing to modify the free plug-ins to define this symbol, and
>   > then to make Emacs to check for it before telling SQLite to load the
>   > plugin.  It would work the same, and it'd also be much easier than
>   > modifying SQLite and having to maintain the modified version, and so on
>   > and so forth.
>
> I don't think that is legally adequate.  I have an idea for a solution
> to that problem, but I need to check it with a lawyer first.
>
> For the mean time, Emacs _should not_ offer any interface to load
> sqlite3 extensions.
>
> But eliminating that is _not_ enough to solve the problem, because
> sqlite3 offers another way to load one!  It defines an SQL function,
> load_extension, to load an extension.  Whatever testing that Emacs
> would try to do on an extension before loading it, load_extension
> would bypass it.
>
> Is there a way we can undefine that SQL function?  The equivalent of
> fmakunbound in Lisp?

Perhaps disabling the SQL extension API would be sufficient ?

The documentation notes that sqlite3_db_config can be used to enable
only the C sqlite3_load_extension API without also enabling the SQL
extension loading API:

    https://www.sqlite.org/c3ref/enable_load_extension.html

The security warning on that page recommends using sqlite3_db_config,
and NOT using sqlite3_enable_load_extension.

    AndyM

Re: master 3d38d1d: Add sqlite3 support to Emacs

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > > But eliminating that is _not_ enough to solve the problem, because
  > > sqlite3 offers another way to load one!  It defines an SQL function,
  > > load_extension, to load an extension.

  > That SQL function is only available if it has been enabled on the C
  > level.  We don't do that, so it's irrelevant.

That's good news.

For now, we should disable the Lisp function to load sqlite3.
Whatever is in master is already being downloaded and run.
It should not offer this capability.

If people develop a safe way to define it, then we can enable it.

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: master 3d38d1d: Add sqlite3 support to Emacs

[Po Lu]

Richard Stallman <rms@gnu.org> writes:

> For now, we should disable the Lisp function to load sqlite3.
> Whatever is in master is already being downloaded and run.
> It should not offer this capability.

Thanks.  Lars, when excising this support, should I remove the configure
code that checks for the presence of `sqlite_load_extension' as well, or
is it used elsewhere?

Re: master 3d38d1d: Add sqlite3 support to Emacs

[Lars Ingebrigtsen]

Po Lu <luangruo@yahoo.com> writes:

> Richard Stallman <rms@gnu.org> writes:
>
>> For now, we should disable the Lisp function to load sqlite3.
>> Whatever is in master is already being downloaded and run.
>> It should not offer this capability.
>
> Thanks.  Lars, when excising this support, should I remove the configure
> code that checks for the presence of `sqlite_load_extension' as well, or
> is it used elsewhere?

I disagree with Richard that we should remove the sqlite-load-extension
function right away, so don't do that.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: master 3d38d1d: Add sqlite3 support to Emacs

[Po Lu]

Lars Ingebrigtsen <larsi@gnus.org> writes:

>> Thanks.  Lars, when excising this support, should I remove the configure
>> code that checks for the presence of `sqlite_load_extension' as well, or
>> is it used elsewhere?

> I disagree with Richard that we should remove the sqlite-load-extension
> function right away, so don't do that.

IANAL, but I think it would be safer to avoid the legal complications of
that by removing it immediately, until the relevant lawyers find a
solution.

Re: master 3d38d1d: Add sqlite3 support to Emacs

[Lars Ingebrigtsen]

Po Lu <luangruo@yahoo.com> writes:

> IANAL, but I think it would be safer to avoid the legal complications of
> that by removing it immediately, until the relevant lawyers find a
> solution.

There aren't any legal complications -- it's just a matter of what we
want to promote by making easy (or not).

I've now implemented the previously mentioned allowlist, and initialised
it with a couple of modules that seemed obviously useful (pcre and
csvtable).

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: master 3d38d1d: Add sqlite3 support to Emacs

[Po Lu]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> I've now implemented the previously mentioned allowlist, and
> initialised it with a couple of modules that seemed obviously useful
> (pcre and csvtable).

The problem is that such a whitelist has to operate on a list of names
by principle, but if the doc string is to be trusted, legitimate plugins
(and proprietary ones) can also be referred to by an absolute file path
to a shared library.

How did you work around this problem?  Thanks.

Re: master 3d38d1d: Add sqlite3 support to Emacs

[Lars Ingebrigtsen]

Po Lu <luangruo@yahoo.com> writes:

> The problem is that such a whitelist has to operate on a list of names
> by principle, but if the doc string is to be trusted, legitimate plugins
> (and proprietary ones) can also be referred to by an absolute file path
> to a shared library.
>
> How did you work around this problem?  Thanks.

I didn't.  As I explained before, there's no technical way to block a
user from loading whatever they way, either via LD_PRELOAD or any number
of other mechanisms.  We can only discourage it, which this allowlist
does.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: master 3d38d1d: Add sqlite3 support to Emacs

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: eliz@gnu.org,  stefankangas@gmail.com,  Richard Stallman <rms@gnu.org>,
>   emacs-devel@gnu.org
> Date: Tue, 14 Dec 2021 11:27:31 +0100
> 
> > How did you work around this problem?  Thanks.
> 
> I didn't.  As I explained before, there's no technical way to block a
> user from loading whatever they way, either via LD_PRELOAD or any number
> of other mechanisms.  We can only discourage it, which this allowlist
> does.

What about Andy Moreton's suggestion to disable loading the extensions
via sqlite3_db_config?  It sounds like a good idea, even if it's
orthogonal to the reason for having a whitelist.

Re: master 3d38d1d: Add sqlite3 support to Emacs

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> What about Andy Moreton's suggestion to disable loading the extensions
> via sqlite3_db_config?  It sounds like a good idea, even if it's
> orthogonal to the reason for having a whitelist.

Do you mean the SQL command for loading extensions?  From my reading of
the documentation, it's not enabled by default -- you have to call a C
level function to enable it, and we don't.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: master 3d38d1d: Add sqlite3 support to Emacs

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: luangruo@yahoo.com,  stefankangas@gmail.com,  rms@gnu.org,
>   emacs-devel@gnu.org
> Date: Tue, 14 Dec 2021 14:15:46 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > What about Andy Moreton's suggestion to disable loading the extensions
> > via sqlite3_db_config?  It sounds like a good idea, even if it's
> > orthogonal to the reason for having a whitelist.
> 
> Do you mean the SQL command for loading extensions?  From my reading of
> the documentation, it's not enabled by default -- you have to call a C
> level function to enable it, and we don't.

Then maybe I misunderstood what Andy was saying, or the documentation
he pointed to (or both).  I'll let Andy respond.

Re: master 3d38d1d: Add sqlite3 support to Emacs

[Andy Moreton]

On Tue 14 Dec 2021, Eli Zaretskii wrote:

>> From: Lars Ingebrigtsen <larsi@gnus.org>
>> Cc: luangruo@yahoo.com,  stefankangas@gmail.com,  rms@gnu.org,
>>   emacs-devel@gnu.org
>> Date: Tue, 14 Dec 2021 14:15:46 +0100
>> 
>> Eli Zaretskii <eliz@gnu.org> writes:
>> 
>> > What about Andy Moreton's suggestion to disable loading the extensions
>> > via sqlite3_db_config?  It sounds like a good idea, even if it's
>> > orthogonal to the reason for having a whitelist.
>> 
>> Do you mean the SQL command for loading extensions?  From my reading of
>> the documentation, it's not enabled by default -- you have to call a C
>> level function to enable it, and we don't.
>
> Then maybe I misunderstood what Andy was saying, or the documentation
> he pointed to (or both).  I'll let Andy respond.

I'm not at all expert on SQL matters - I read the sqlite documentation
which points out that there are two ways to allow loading of sqlite
extensions from C:

a) sqlite3_db_config(db,SQLITE_DBCONFIG_ENABLE_LOAD_EXTENSION,..)
   - enables sqlite3_load_extension()
   - does not enable SQL function "load_extension"

b) sqlite3_enable_load_extension()
   - enables sqlite3_load_extension()
   - ALSO enables SQL function "load_extension"

So if sqlite extensions are to be allowed in emacs, option (a) should be
preferred. This is explicitly called out as a security issue in the docs.

Loading sqlite extensions should be disabled by default, and only be
enabled by explicit user configuration.

    AndyM

Re: master 3d38d1d: Add sqlite3 support to Emacs

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > The documentation notes that sqlite3_db_config can be used to enable
  > only the C sqlite3_load_extension API without also enabling the SQL
  > extension loading API:

Is it desirable to enable the C version of sqlite3_load_extension?
What uses that?

I have a feeling that if can only do harm, not good -- that either it
will never be used, or it could be used to load nonfree eetxnsions.
Why take a risk?

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: master 3d38d1d: Add sqlite3 support to Emacs

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > IANAL, but I think it would be safer to avoid the legal complications of
  > that by removing it immediately, until the relevant lawyers find a
  > solution.

You have the right basic approach to this problem.  The problem is
grave and hard; we don't know whether there is an adequate solution.
We won't know unless/until we find one.

While a feature is in that state of doubt, it should not be included.
We should install it if and when we know it is correct to do so.
Installing it prematurely is unwise, so we need to de-install it.

I want to correct one detail.  This is not a legal problem, it's a
moral problem.  There is no "answer" that lawyers could tell us that
would fix it.

We have discussed technical solutions that could make dynamic loading
of modules morally ok, but implementing them seems like a hassle.  It
looks like few users will use them anyway, which would imply that
implementing a solution is not worth the trouble.

If we confirm that, it will follows that the right thing to do is to
keep dynamic loading of sqlite3 modules completely off in Emacs.
It seems that's easy.

Unless/until we know that it is ok to give Emacs the dynamic sqlite3
module feature, we should not install it.

Po Lu, would you please remove that feature (disable that code)?

If we do find later that it is ok to enable that feature, it won't be
hard to install it then.

Lars is right that there are always ways for users do modify a free
program to do whatever they wish.  That's the nature of free software.
That's how things should be.

So if we were trying to make it _impossible_ for users to modify Emacs
to run with a nonfree dynamically loaded sqlite3 module, that would be
futile -- and wrong.  As developers of a free program, we can't _stop_
users from modifying it to do whatever they wish, and we don't want to
try.

Which is why this issue is not about "stopping" users from making such
modifications, or whether we can "stop" them.  Those questions are
distractions.  This question is about what Emacs _as we distribute it_
does, and what it should do.

Unless we find a way to make the sqlite3 dynamical module capability
ok, we should not implement that capability.

Po Lu, would you please turn off that sqlite3 dynamical module capability?

Lars metioned something called LD_PRELOAD.  I don't know what that is,
and I can't find it in the documentation I have here.  I don't know
whether it makes a difference for this issue, and I would like to
study that question.

Would someone please point me at an explanation of what LD_PRELOAD
does, with docs for how to use it?  Also, which part of the GNU/Linux
system implements it?

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: master 3d38d1d: Add sqlite3 support to Emacs

[Lars Ingebrigtsen]

Richard Stallman <rms@gnu.org> writes:

> Unless/until we know that it is ok to give Emacs the dynamic sqlite3
> module feature, we should not install it.
>
> Po Lu, would you please remove that feature (disable that code)?

No, don't do that.

> If we do find later that it is ok to enable that feature, it won't be
> hard to install it then.

There's an allowlist in place.  Only the pcre and csvtable modules (both
free modules) can be installed now via the current loading mechanism.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: master 3d38d1d: Add sqlite3 support to Emacs

[Lars Ingebrigtsen]

Richard Stallman <rms@gnu.org> writes:

> I have a feeling that if can only do harm, not good -- that either it
> will never be used, or it could be used to load nonfree eetxnsions.

The use case is to load the pcre module, which will allow us to list
stored data based on regexp matches.  I.e., it will give users greater
power to inspect .sqlite files.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Contradictiory directions (Was: Re: master 3d38d1d: Add sqlite3 support to Emacs)

[Po Lu]

Richard Stallman <rms@gnu.org> writes:

> Unless/until we know that it is ok to give Emacs the dynamic sqlite3
> module feature, we should not install it.
>
> Po Lu, would you please remove that feature (disable that code)?

Lars Ingebrigtsen <larsi@gnus.org> writes:

> No, don't do that.

Who do I listen to..? It is already confusing enough to participate in
the development of a large piece of software in my spare time as it is,
so please don't confuse me further with contradictory instructions.

That being said, I'm personally in favour of removing the code.  It
doesn't seem right to leave such a half baked solution to a serious
problem in place.

> There's an allowlist in place.  Only the pcre and csvtable modules (both
> free modules) can be installed now via the current loading mechanism.

It's still based on looking at the names of modules: proprietary modules
could easily be renamed so that their filenames are the same as the free
ones, and vice versa: it is not concrete at all.

The PCRE and csvtable modules are also in the public domain.
Proprietary versions of them could be created ino the future.

BTW, the term "allowlist" is confusing.  It took me a while to guess its
meaning.  Why not use the industry-standard term "whitelist" instead?

Re: Contradictiory directions

[Lars Ingebrigtsen]

Po Lu <luangruo@yahoo.com> writes:

> Who do I listen to..?

Eli and I are the maintainers.

> It is already confusing enough to participate in
> the development of a large piece of software in my spare time as it is,
> so please don't confuse me further with contradictory instructions.

Yes, it's confusing when other people are trying to give you orders, but
you can just disregard them.

> It's still based on looking at the names of modules: proprietary modules
> could easily be renamed so that their filenames are the same as the free
> ones, and vice versa: it is not concrete at all.
>
> The PCRE and csvtable modules are also in the public domain.
> Proprietary versions of them could be created ino the future.

There are no guarantees in this world.  Anybody could be making
proprietary versions of absolutely all modules Emacs is loading,
including libc.so, and there's no technical ways of stopping Emacs from
loading them.

> BTW, the term "allowlist" is confusing.  It took me a while to guess its
> meaning.  Why not use the industry-standard term "whitelist" instead?

The industry standard is allowlist/blocklist.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: master 3d38d1d: Add sqlite3 support to Emacs

[Po Lu]

Richard Stallman <rms@gnu.org> writes:

> Lars metioned something called LD_PRELOAD.  I don't know what that is,
> and I can't find it in the documentation I have here.  I don't know
> whether it makes a difference for this issue, and I would like to
> study that question.
>
> Would someone please point me at an explanation of what LD_PRELOAD
> does, with docs for how to use it?  Also, which part of the GNU/Linux
> system implements it?

It's implemented by the dynamic linker component of the GNU C Library.

See the sections "environment" and "files" of the manual page for ld.so,
but if that's not on your system, here are the relevant parts for your
convenience.


       LD_PRELOAD
              A  list  of additional, user-specified, ELF shared objects to be
              loaded before all others.  This feature can be  used  to  selec‐
              tively override functions in other shared objects.

              The  items of the list can be separated by spaces or colons, and
              there is no support for escaping either separator.  The  objects
              are  searched  for using the rules given under DESCRIPTION.  Ob‐
              jects are searched for and added to the link map in the left-to-
              right order specified in the list.

              In  secure-execution  mode, preload pathnames containing slashes
              are ignored.  Furthermore, shared  objects  are  preloaded  only
              from  the standard search directories and only if they have set-
              user-ID mode bit enabled (which is not typical).

              Within the names specified in the LD_PRELOAD list,  the  dynamic
              linker  understands  the tokens $ORIGIN, $LIB, and $PLATFORM (or
              the versions using curly braces around the names)  as  described
              above  in  Dynamic  string  tokens.  (See also the discussion of
              quoting under the description of LD_LIBRARY_PATH.)

              There are various methods of specifying  libraries  to  be  pre‐
              loaded, and these are handled in the following order:

              (1) The LD_PRELOAD environment variable.

              (2) The  --preload command-line option when invoking the dynamic
                  linker directly.

              (3) The /etc/ld.so.preload file (described below).

       /etc/ld.so.preload
              File  containing  a  whitespace-separated list of ELF shared ob‐
              jects to be loaded before the program.  See  the  discussion  of
              LD_PRELOAD above.  If both LD_PRELOAD and /etc/ld.so.preload are
              employed, the libraries specified by  LD_PRELOAD  are  preloaded
              first.  /etc/ld.so.preload has a system-wide effect, causing the
              specified libraries to be preloaded for all  programs  that  are
              executed  on  the  system.  (This is usually undesirable, and is
              typically employed only as an emergency remedy, for example,  as
              a temporary workaround to a library misconfiguration issue.)

Re: Contradictiory directions

[Po Lu]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> There are no guarantees in this world.  Anybody could be making
> proprietary versions of absolutely all modules Emacs is loading,
> including libc.so, and there's no technical ways of stopping Emacs from
> loading them.

I think the idea is that for us to _distribute_ a version of Emacs that
allows to dynamically load proprietary modules is wrong and sets a bad
example for the GNU project.

> The industry standard is allowlist/blocklist.

If so, it is certainly a standard I don't know about.  In nearly three
decades, I've heard many variants of "list", but never "allowlist" or
"blocklist".  Can we agree to use the terminology that everyone knows
about in Emacs, to keep the situation simple?

Re: Contradictiory directions

[Lars Ingebrigtsen]

Po Lu <luangruo@yahoo.com> writes:

> I think the idea is that for us to _distribute_ a version of Emacs that
> allows to dynamically load proprietary modules is wrong and sets a bad
> example for the GNU project.

It is impossible to disallow such a thing, so I'm not sure what your
point is.

>> The industry standard is allowlist/blocklist.
>
> If so, it is certainly a standard I don't know about.  In nearly three
> decades, I've heard many variants of "list", but never "allowlist" or
> "blocklist".  Can we agree to use the terminology that everyone knows
> about in Emacs, to keep the situation simple?

Seems simple enough to me.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Contradictiory directions

[Po Lu]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> It is impossible to disallow such a thing, so I'm not sure what your
> point is.

It's bad to distribute a version of Emacs capable of such a thing.
Users are of course free to do whatever they want with their copies, but
we are morally and legally responsible for the versions of Emacs that we
distribute.

glibc (and hence, LD_PRELOAD) is special in this regard: it is a system
library.  There is a detailed explanation somewhere I don't recall
anymore, but there is a simplified version here:
https://www.gnu.org/licenses/why-not-lgpl.html.

>> If so, it is certainly a standard I don't know about.  In nearly three
>> decades, I've heard many variants of "list", but never "allowlist" or
>> "blocklist".  Can we agree to use the terminology that everyone knows
>> about in Emacs, to keep the situation simple?

> Seems simple enough to me.

So we agree to use the existing terms "whitelist" and "blacklist" then?
LGTM, thanks!

Re: Contradictiory directions

[Lars Ingebrigtsen]

Po Lu <luangruo@yahoo.com> writes:

>> It is impossible to disallow such a thing, so I'm not sure what your
>> point is.
>
> It's bad to distribute a version of Emacs capable of such a thing.

Uhm...  then it's bad, I guess?  Since all versions of Emacs have been,
since the very first one, capable of that.

>>> If so, it is certainly a standard I don't know about.  In nearly three
>>> decades, I've heard many variants of "list", but never "allowlist" or
>>> "blocklist".  Can we agree to use the terminology that everyone knows
>>> about in Emacs, to keep the situation simple?
>
>> Seems simple enough to me.
>
> So we agree to use the existing terms "whitelist" and "blacklist" then?
> LGTM, thanks!

We're using the existing terms allowlist/blocklist.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Contradictiory directions

[Po Lu]

Lars Ingebrigtsen <larsi@gnus.org> writes:

>> It's bad to distribute a version of Emacs capable of such a thing.

> Uhm...  then it's bad, I guess?  Since all versions of Emacs have been,
> since the very first one, capable of that.

We did not gain any type of dynamic module loading feature until Emacs
25.

> We're using the existing terms allowlist/blocklist.

"Blacklist" and "whitelist" appear in the Emacs source tree a total of
432 times, while "allowlist" and "blocklist" appear a total of 259 times
exclusively in the context of mh-e.

So it seems to be terminology specific to mh-e, with no reason to
warrant its adoption throughout Emacs.

Re: Contradictiory directions

[Lars Ingebrigtsen]

Po Lu <luangruo@yahoo.com> writes:

> We did not gain any type of dynamic module loading feature until Emacs
> 25.

I'm not talking about dynamic Emacs modules.  I'm talking about basic
libraries.  We can't check whether whatever libraries we're loading,
whether it's libc.so or libsrvg.so or whatever, aren't proprietary
variations on the libraries we're expecting.

> So it seems to be terminology specific to mh-e, with no reason to
> warrant its adoption throughout Emacs.

The reason is that the world has moved on to the new terms.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Contradictiory directions

[Po Lu]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> I'm not talking about dynamic Emacs modules.  I'm talking about basic
> libraries.  We can't check whether whatever libraries we're loading,
> whether it's libc.so or libsrvg.so or whatever, aren't proprietary
> variations on the libraries we're expecting.

These are system libraries, all of which are either free or have free
replacements.  I don't think we allow features that depend on
proprietary libraries that have no free replacement.  And to distribute
a binary of Emacs that links against a non-free non-system library would
be illegal.

>> So it seems to be terminology specific to mh-e, with no reason to
>> warrant its adoption throughout Emacs.
>
> The reason is that the world has moved on to the new terms.

It certainly hasn't: this was the first time I ever came across the term
"allowlist" being used, and it was in the form of an email, not code.

Even if the world has "moved on" (which is hardly a given), software
(Emacs even more so) has historically used the "old" terms, which there
is no need to change.  So as I said, can we please keep the situation
simple by using the terminology which we have always used, which is to
say, "blacklist" and "whitelist".

Re: Contradictiory directions

[tomas]

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

On Wed, Dec 15, 2021 at 04:13:39PM +0800, Po Lu wrote:

[...]

> >> So it seems to be terminology specific to mh-e, with no reason to
> >> warrant its adoption throughout Emacs.
> >
> > The reason is that the world has moved on to the new terms.
> 
> It certainly hasn't: this was the first time I ever came across the term
> "allowlist" being used, and it was in the form of an email, not code.
> 
> Even if the world has "moved on" (which is hardly a given), software
> (Emacs even more so) has historically used the "old" terms, which there
> is no need to change.  So as I said, can we please keep the situation
> simple by using the terminology which we have always used, which is to
> say, "blacklist" and "whitelist".

This is a politically loaded discussion. Still, I think it is important.
If there is a reason to assume that "blacklist"/"whitelist" might offend
some people, I think it does make sense to look for alternatives.

Perhaps it doesn't make sense to mass-patch old code, but when writing
new code... why not?

Cheers
-- 
t

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: Contradictiory directions

[Lele Gaifax]

Po Lu <luangruo@yahoo.com> writes:

> Lars Ingebrigtsen <larsi@gnus.org> writes:
>>
>> The reason is that the world has moved on to the new terms.
>
> It certainly hasn't: this was the first time I ever came across the term
> "allowlist" being used, and it was in the form of an email, not code.
>
> Even if the world has "moved on" (which is hardly a given), software
> (Emacs even more so) has historically used the "old" terms, which there
> is no need to change.  So as I said, can we please keep the situation
> simple by using the terminology which we have always used, which is to
> say, "blacklist" and "whitelist".

The world is slowly moving toward a more "inclusive" and "politically correct"
terminology, because using "black" and "white" for such things may sound
inappropriate, as "master"/"slave" in other contexts.

ciao, lele.
-- 
nickname: Lele Gaifax | Quando vivrò di quello che ho pensato ieri
real: Emanuele Gaifas | comincerò ad aver paura di chi mi copia.
lele@metapensiero.it  |                 -- Fortunato Depero, 1929.

Re: Contradictiory directions

[Po Lu]

<tomas@tuxteam.de> writes:

> This is a politically loaded discussion. Still, I think it is important.
> If there is a reason to assume that "blacklist"/"whitelist" might offend
> some people, I think it does make sense to look for alternatives.

This is not a political discussion, but one based on technical issues,
namely how using two different terms to refer to the same thing hinders
the development of Emacs.

The only goal is to develop free software, which necessitates not being
sidetracked by the attempts of other movements (which may or may not be
admirable) to introduce new terminology.

There is a node "Other Politics" in the Information for Maintainers of
GNU Software, which says:

  A GNU package should not seriously advocate any other political
  causes.  Not that the GNU Project opposes those other causes.  Rather,
  it is neutral on them, and GNU packages should be neutral too.

And my discussion proceeded on those neutral lines as well.  Please do
not bring political issues into this.

Re: Contradictiory directions

[tomas]

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

On Wed, Dec 15, 2021 at 05:49:30PM +0800, Po Lu wrote:

Hi,

this is going to be my last post to this thread. I think it isn't useful
to extend those discussions beyond some point.

> <tomas@tuxteam.de> writes:
> 
> > This is a politically loaded discussion. Still, I think it is important.
> > If there is a reason to assume that "blacklist"/"whitelist" might offend
> > some people, I think it does make sense to look for alternatives.
> 
> This is not a political discussion, but one based on technical issues,

[...]

This "we decide exclusively on technical grounds" is usually a higly
political decision hidden behind a tree. My hunch is that this is one of
those cases.

But, as I said above, I'll rest my case. We have stated our positions,
we won't convince each other, so that's the maximum use we can expect
this thread can have.

Let's agree to differ.

Cheers
-- 
t

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: Contradictiory directions

[Po Lu]

tomas@tuxteam.de writes:

> This "we decide exclusively on technical grounds" is usually a higly
> political decision hidden behind a tree. My hunch is that this is one of
> those cases.

No, it is not.  I would not agree to a change from (for example) "frame"
to "window" and from "window" to "pane" for the exact same reason.

Re: Contradictiory directions

[Óscar Fuentes]

Po Lu <luangruo@yahoo.com> writes:

> It's still based on looking at the names of modules: proprietary modules
> could easily be renamed so that their filenames are the same as the free
> ones, and vice versa: it is not concrete at all.

Propietary modules can define any symbol, so the
"this_module_is_fine_with_gnus" or whatever trick is used on Emacs and
gcc modules is even less of a solution. I can foresee a propietary
module playing that trick, but changing the name of the module and
creating a name collision with some of the most popular modules out
there is a bit too risky even for the most adventurous propietary
vendor.

> The PCRE and csvtable modules are also in the public domain.
> Proprietary versions of them could be created ino the future.

So you just decidead that all those versions that allow to distribute
non-free versions of the code are incompatible with the GPL after all?
<sigh>

> BTW, the term "allowlist" is confusing.  It took me a while to guess its
> meaning.  Why not use the industry-standard term "whitelist" instead?

Today you are in the mood of picking an argument, aren't you? ;-)

Re: Contradictiory directions

[Po Lu]

Óscar Fuentes <ofv@wanadoo.es> writes:

> Propietary modules can define any symbol, so the
> "this_module_is_fine_with_gnus" or whatever trick is used on Emacs and
> gcc modules is even less of a solution. I can foresee a propietary
> module playing that trick, but changing the name of the module and
> creating a name collision with some of the most popular modules out
> there is a bit too risky even for the most adventurous propietary
> vendor.

Then as RMS said, we should remove the feature wholesale, until a
solution is found.

> So you just decidead that all those versions that allow to distribute
> non-free versions of the code are incompatible with the GPL after all?

GPL compatibility is not the solution to the problem here, which is a
moral one.

> Today you are in the mood of picking an argument, aren't you? ;-)

I'm not picking an argument, only noting what I found to be confusing.

Re: Contradictiory directions

[Óscar Fuentes]

Po Lu <luangruo@yahoo.com> writes:

> Óscar Fuentes <ofv@wanadoo.es> writes:
>
>> Propietary modules can define any symbol, so the
>> "this_module_is_fine_with_gnus" or whatever trick is used on Emacs and
>> gcc modules is even less of a solution. I can foresee a propietary
>> module playing that trick, but changing the name of the module and
>> creating a name collision with some of the most popular modules out
>> there is a bit too risky even for the most adventurous propietary
>> vendor.
>
> Then as RMS said, we should remove the feature wholesale, until a
> solution is found.

My point is that if the symbol trick is considered an acceptable
solution, name-based blocking should be acceptable too because it is
much more effective in practice.

Re: Contradictiory directions

[Po Lu]

Óscar Fuentes <ofv@wanadoo.es> writes:

>> Then as RMS said, we should remove the feature wholesale, until a
>> solution is found.

> My point is that if the symbol trick is considered an acceptable
> solution

My understanding is that the symbol trick is considered acceptable
because it will be more likely to hold up in court to mean that whoever
wrote the non-free module fully understood that it had to be compatible
with the GPL.  (And it certainly took a long time to devise that method,
as there were already patches for Emacs 20 adding dynamic loading
support, but it took us all the way until Emacs 25 to get where we are
now.)

But apparently SQLite modules, even those intended for use with Emacs,
are not legally required to comply with the GPL, so that is out of the
question here.

Re: Contradictiory directions

[Dmitry Gutov]

On 15.12.2021 12:49, Po Lu wrote:
> This is not a political discussion, but one based on technical issues,
> namely how using two different terms to refer to the same thing hinders
> the development of Emacs.

It's a discussion where one side is aware of the political connotations 
of the terms and the reasons why "the world has moved on from them", and 
another stays willfully ignorant of them.

Re: Contradictiory directions

[Po Lu]

Dmitry Gutov <dgutov@yandex.ru> writes:

> It's a discussion where one side is aware of the political
> connotations of the terms and the reasons why "the world has moved on
> from them", and another stays willfully ignorant of them.

Either way, I did not start a discussion about politics, so please don't
turn it into one.

Would you accept a change from "window" to "glass sheet", especially if
"window" will still be used inside Emacs in many places?

Developing software is hard enough, so please try not to make it even
more confusing with sudden (and partial) changes in terminology.

Thanks.

Re: Contradictiory directions

[Lars Ingebrigtsen]

Po Lu <luangruo@yahoo.com> writes:

> These are system libraries, all of which are either free or have free
> replacements.  I don't think we allow features that depend on
> proprietary libraries that have no free replacement.

We don't link against such libraries, but there's nothing we can do to
disallow a user from doing so.  Fortunately.

> And to distribute a binary of Emacs that links against a non-free
> non-system library would be illegal.

Distribution is a whole nother kettle of fish.

> Even if the world has "moved on" (which is hardly a given), software
> (Emacs even more so) has historically used the "old" terms, which there
> is no need to change.  So as I said, can we please keep the situation
> simple by using the terminology which we have always used, which is to
> say, "blacklist" and "whitelist".

Sorry, no.  And I find it pretty odd to quibble about
allowlist/blocklist -- they're clearly better terms than the vague
whitelist/blacklist terms.  They're self explanatory terms, while the
old ones were jargon you had to learn.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Contradictiory directions

[Óscar Fuentes]

Po Lu <luangruo@yahoo.com> writes:

> Óscar Fuentes <ofv@wanadoo.es> writes:
>
>>> Then as RMS said, we should remove the feature wholesale, until a
>>> solution is found.
>
>> My point is that if the symbol trick is considered an acceptable
>> solution
>
> My understanding is that the symbol trick is considered acceptable
> because it will be more likely to hold up in court to mean that whoever
> wrote the non-free module fully understood that it had to be compatible
> with the GPL.

So someone at the FSF thought that creating a module, which requires
studying, understanding and complying with a bunch of technical
requisites mandated by the host application (Emacs or Gcc), could open
the possibility of a credible "I didn't care to read the license", but
using a GPL'ed library, that often requires less technical effort, is
not equally impacted by the same risk :-/

> But apparently SQLite modules, even those intended for use with Emacs,
> are not legally required to comply with the GPL, so that is out of the
> question here.

Nothing is legally required to comply with the GPL. The FSF does not
dictate law, it uses a license and hopes for the best.

The scenario of someone sneaking in a non-free SQLite extension against
the user's wishes is a bit far-fetched, to say the least. So we are
wasting a lot of energy worrying about how to effectively inconvenience
our users for "protecting" them from an unlikely event no matter how
much limitations are imposed on the feature being discussed. I thought
that the gcc/llvm debacle would be understood at this point.

Re: Contradictiory directions

[Po Lu]

Óscar Fuentes <ofv@wanadoo.es> writes:

> Nothing is legally required to comply with the GPL. The FSF does not
> dictate law, it uses a license and hopes for the best.

IANAL, but the FSF has them, and as far as they can see, the GPL is a
valid license.  Not to mention that it has already been declared valid
in court many times.

So instead of being pedantic, it is reasonable to say that people
creating Emacs and GCC modules are legally required to comply with the
GPL.

> The scenario of someone sneaking in a non-free SQLite extension
> against the user's wishes is a bit far-fetched, to say the least.
>
> So we are wasting a lot of energy worrying about how to effectively
> inconvenience our users for "protecting" them from an unlikely event
> no matter how much limitations are imposed on the feature being
> discussed.  I thought that the gcc/llvm debacle would be understood at
> this point.

That sounds like defeatism.  Whether or not it will work, we are going
to try, and when we discover a problem, we are going to try to solve it
the best way we can.

See https://www.gnu.org/philosophy/compromise.html.

Re: Contradictiory directions (Was: Re: master 3d38d1d: Add sqlite3 support to Emacs)

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: Richard Stallman <rms@gnu.org>,  eliz@gnu.org,  stefankangas@gmail.com,
>   emacs-devel@gnu.org
> Date: Wed, 15 Dec 2021 15:17:55 +0800
> 
> It doesn't seem right to leave such a half baked solution to a
> serious problem in place.

Please be more polite.  There's nothing half-baked about the code
that's on master now.

Re: Contradictiory directions

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: emacs-devel@gnu.org
> Date: Wed, 15 Dec 2021 18:24:05 +0800
> 
> Óscar Fuentes <ofv@wanadoo.es> writes:
> 
> > Propietary modules can define any symbol, so the
> > "this_module_is_fine_with_gnus" or whatever trick is used on Emacs and
> > gcc modules is even less of a solution. I can foresee a propietary
> > module playing that trick, but changing the name of the module and
> > creating a name collision with some of the most popular modules out
> > there is a bit too risky even for the most adventurous propietary
> > vendor.
> 
> Then as RMS said, we should remove the feature wholesale, until a
> solution is found.

You mean, also remove the loadable modules from GCC, GNU Make, Gawk,
etc.?

Re: Contradictiory directions

[Dmitry Gutov]

On 15.12.2021 15:31, Po Lu wrote:
> Dmitry Gutov <dgutov@yandex.ru> writes:
> 
>> It's a discussion where one side is aware of the political
>> connotations of the terms and the reasons why "the world has moved on
>> from them", and another stays willfully ignorant of them.
> 
> Either way, I did not start a discussion about politics, so please don't
> turn it into one.

You started to ask questions which are easily answered by doing some 
research (via searching the web) outside of this mailing list.

There is indeed little point in rehashing this argument which has 
occurred in a myriad of places by now.

> Would you accept a change from "window" to "glass sheet", especially if
> "window" will still be used inside Emacs in many places?

Irrelevant.

> Developing software is hard enough, so please try not to make it even
> more confusing with sudden (and partial) changes in terminology.

There is nothing confusing in "allowlist" and "denylist". Those are 
plain English.

FWIW, personally I'm in no hurry to move on from "white/black" and 
"master/slave" in all my projects across the board, but it's clear by 
now that such a move must occur eventually. So arguing about undoing 
such changes that have already been made is counter-productive.

Re: Contradictiory directions

[Po Lu]

Eli Zaretskii <eliz@gnu.org> writes:

> You mean, also remove the loadable modules from GCC, GNU Make, Gawk,
> etc.?

No, no, just the SQLite module feature, where the question of GPL
compatiblility doesn't really apply.

Thanks.

Re: master 3d38d1d: Add sqlite3 support to Emacs

[Alexandre Garreau]

Le merkredo, 15-a de decembro 2021, 6-a horo kaj 15:22 CET Richard 
Stallman a écrit :
> Lars metioned something called LD_PRELOAD.  I don't know what that is,
> and I can't find it in the documentation I have here.  I don't know
> whether it makes a difference for this issue, and I would like to
> study that question.
> 
> Would someone please point me at an explanation of what LD_PRELOAD
> does, with docs for how to use it?  Also, which part of the GNU/Linux
> system implements it?

It’s an environment variable making ld.so preload dynamical libraries 
before any other, so that you can overwrite any C function with another, 
just by specifying a .so library implementing it in that variable.  You 
can use that to tweak the behavior of any program.  Lars was using that as 
an argument to state it is futile to stop users from running proprietary 
software if they want to since they can do it anyway that way.

I agree the issue is not stopping users, but making them run such software 
anyway, whatever their specific will regarding emacs.

Re: Contradictiory directions

[dick]

PL> it is reasonable to say that people creating Emacs and GCC
PL> modules are legally required to comply with the GPL

Wow, you cannot both proscribe legality and hedge with "reasonable to
say" in the same sentence.

That you would publicly make such legal pronouncements while disclaiming
"IANAL" says a lot about you and probably your code.

Re: Contradictiory directions (Was: Re: master 3d38d1d: Add sqlite3 support to Emacs)

[Alexandre Garreau]

Le merkredo, 15-a de decembro 2021, 8-a horo kaj 17:55 CET Po Lu a écrit :
> > There's an allowlist in place.  Only the pcre and csvtable modules
> > (both free modules) can be installed now via the current loading
> > mechanism.
> It's still based on looking at the names of modules: proprietary modules
> could easily be renamed so that their filenames are the same as the
> free ones, and vice versa: it is not concrete at all.

I think it’s a little ridiculous to fear that.  That’s obvious malicious 
intent, and distributions should refuse that anyway.  If a user does a 
such thing, it’s their intent, and their responsibility.  They decided to 
choose oppression, and we won’t be able to stop them (and it’s not 
illegal, copyright is only about distribution, copying, not usage)

> The PCRE and csvtable modules are also in the public domain.
> Proprietary versions of them could be created ino the future.

*That*’s worrying.  Keeps me thinking the gpl-compatibility symbol is the 
only Right Way to go.  We may completely disallow modules, with a call to 
implementation/TODO about allowing them when they contain a such symbol, 
and after that another one about hacking those libs to make them so, and 
providing patches to distribution.

But the first step is blocking them.

> BTW, the term "allowlist" is confusing.  It took me a while to guess its
> meaning.  Why not use the industry-standard term "whitelist" instead?

I disagree, allowlist looks weird and esoteric to me but it perfectly 
describes what it is.  Maybe Lars just participated in this modern trend 
of avoiding politically uncorrect/connotated words in technical jargon 
(such as positivity for “white” and negativity for “black”, although I’m 
still uncertain about it’s for sure historically related to racism; actual 
sociological/historical data welcome!); but still the side effect is those 
technical words becomes less like jargon and more understandable by laymen 
(or layperson? I don’t even understand the morphological nor etymological 
construction of layman anyway…) and newcomers (when they’re chose wisely, 
like here), I’m in favor of that, let me state my support of it.

Re: master 3d38d1d: Add sqlite3 support to Emacs

[Eli Zaretskii]

> From: Andy Moreton <andrewjmoreton@gmail.com>
> Date: Tue, 14 Dec 2021 23:41:14 +0000
> 
> I'm not at all expert on SQL matters - I read the sqlite documentation
> which points out that there are two ways to allow loading of sqlite
> extensions from C:
> 
> a) sqlite3_db_config(db,SQLITE_DBCONFIG_ENABLE_LOAD_EXTENSION,..)
>    - enables sqlite3_load_extension()
>    - does not enable SQL function "load_extension"
> 
> b) sqlite3_enable_load_extension()
>    - enables sqlite3_load_extension()
>    - ALSO enables SQL function "load_extension"
> 
> So if sqlite extensions are to be allowed in emacs, option (a) should be
> preferred. This is explicitly called out as a security issue in the docs.
> 
> Loading sqlite extensions should be disabled by default, and only be
> enabled by explicit user configuration.

But we don't call sqlite3_enable_load_extension, we call only
sqlite3_load_extension.  What does this mean for load_extension -- is
it enabled or disabled?

Re: Contradictiory directions

[Alexandre Garreau]

Le merkredo, 15-a de decembro 2021, 13-a horo kaj 44:48 CET Óscar Fuentes 
a écrit :
> The scenario of someone sneaking in a non-free SQLite extension against
> the user's wishes is a bit far-fetched, to say the least. So we are
> wasting a lot of energy worrying about how to effectively inconvenience
> our users for "protecting" them from an unlikely event no matter how
> much limitations are imposed on the feature being discussed. I thought
> that the gcc/llvm debacle would be understood at this point.

Many systems have been showed to disrespect users’ choice that way.  It’s 
a little stretched for debian, impossible for trisquel, but imaginable on 
ubuntu, and likely under mac os x, ios, windows and android (and these are 
way more used).

Re: Contradictiory directions

[Alexandre Garreau]

Le merkredo, 15-a de decembro 2021, 14-a horo kaj 4:16 CET Po Lu a écrit :
> Óscar Fuentes <ofv@wanadoo.es> writes:
> 
> 
> 
> > Nothing is legally required to comply with the GPL. The FSF does not
> > dictate law, it uses a license and hopes for the best.
> 
> IANAL, but the FSF has them, and as far as they can see, the GPL is a
> valid license.  Not to mention that it has already been declared valid
> in court many times.

Copyright is about distribution, not usage.  A creator of an extension can 
use it how person wish, whatever the license, as long as it’s done in 
private.  Rarely a law takes the burden to stop you from doing something 
that doesn’t impact others.

> So instead of being pedantic, it is reasonable to say that people
> creating Emacs and GCC modules are legally required to comply with the
> GPL.

Copyright is not made to restrict copyrights “owners”, but users.

Re: Contradictiory directions (Was: Re: master 3d38d1d: Add sqlite3 support to Emacs)

[tomas]

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

On Wed, Dec 15, 2021 at 03:34:49PM +0100, Alexandre Garreau wrote:
> Le merkredo, 15-a de decembro 2021, 8-a horo kaj 17:55 CET Po Lu a écrit :

[...]

> > BTW, the term "allowlist" is confusing.  It took me a while to guess its
> > meaning.  Why not use the industry-standard term "whitelist" instead?
> 
> I disagree, allowlist looks weird and esoteric to me but it perfectly 
> describes what it is [...]

This will always be a controversial point, since there are strong
feelings on both sides. It would be good if the project as such finds a
position on this issue, to avoid recurring discussions.

Cheers
-- 
tomás

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: Contradictiory directions

[Alexandre Garreau]

Le merkredo, 15-a de decembro 2021, 11-a horo kaj 14:41 CET Óscar Fuentes 
a écrit :
> Po Lu <luangruo@yahoo.com> writes:
> 
> 
> 
> > It's still based on looking at the names of modules: proprietary
> > modules could easily be renamed so that their filenames are the same
> > as the free ones, and vice versa: it is not concrete at all.
> 
> Propietary modules can define any symbol, so the
> "this_module_is_fine_with_gnus" or whatever trick is used on Emacs and
> gcc modules is even less of a solution. I can foresee a propietary
> module playing that trick, but changing the name of the module and
> creating a name collision with some of the most popular modules out
> there is a bit too risky even for the most adventurous propietary
> vendor.

except a symbol with written “gpl-compatible” on it might be legally akin 
to “I accept my module can be relicensed to GPLv3”, which may be akin to a 
license.  From there, we could feel allowed to distribute the library and 
modified versions of it at will, so that would “suffice” to make it free-
software.

> > The PCRE and csvtable modules are also in the public domain.
> > Proprietary versions of them could be created ino the future.
> 
> So you just decidead that all those versions that allow to distribute
> non-free versions of the code are incompatible with the GPL after all?
> <sigh>

No, but enough for them to *potentially become* so *without being noticed* 
by emacs or even the users themselves…

…what if one day mac os x or ubuntu or windows starts bundling a version 
of sqlite with special “improved” extensions that are made proprietary? we 
don’t want that.  We want emacs to break in that case, and potentially the 
users to do something to become themselves responsible of a such 
combination of software.

> > BTW, the term "allowlist" is confusing.  It took me a while to guess
> > its meaning.  Why not use the industry-standard term "whitelist"
> > instead?
> Today you are in the mood of picking an argument, aren't you? ;-)

The more we feel in an adversarial mood, the more we should attempt to 
adopt a kind and benevolent mindset.  That’s best for everybody, for 
emacs, and even four each one’s own arguments.

Re: Contradictiory directions

[Alexandre Garreau]

Le merkredo, 15-a de decembro 2021, 8-a horo kaj 23:17 CET Lars 
Ingebrigtsen a écrit :
> > It's still based on looking at the names of modules: proprietary
> > modules could easily be renamed so that their filenames are the same
> > as the free ones, and vice versa: it is not concrete at all.
> > 
> > The PCRE and csvtable modules are also in the public domain.
> > Proprietary versions of them could be created ino the future.
> 
> There are no guarantees in this world.  Anybody could be making
> proprietary versions of absolutely all modules Emacs is loading,
> including libc.so, and there's no technical ways of stopping Emacs from
> loading them.

No, libc is copylefted, and proprietariness is in great part *due* to 
copyright.  Without it, or rather, with its license hereditarilly being 
made free, the only way to make it proprietary is obfuscation (including 
compiling without giving source, agreed).  But you can still RE the thing, 
it’s still “legally free” (like linux’s blobs).  There’s at least this 
guarranty.

> > BTW, the term "allowlist" is confusing.  It took me a while to guess
> > its meaning.  Why not use the industry-standard term "whitelist"
> > instead?
> The industry standard is allowlist/blocklist.

since when? that makes me curious

Re: Contradictiory directions

[Óscar Fuentes]

Alexandre Garreau <galex-713@galex-713.eu> writes:

> Le merkredo, 15-a de decembro 2021, 13-a horo kaj 44:48 CET Óscar Fuentes 
> a écrit :
>> The scenario of someone sneaking in a non-free SQLite extension against
>> the user's wishes is a bit far-fetched, to say the least. So we are
>> wasting a lot of energy worrying about how to effectively inconvenience
>> our users for "protecting" them from an unlikely event no matter how
>> much limitations are imposed on the feature being discussed. I thought
>> that the gcc/llvm debacle would be understood at this point.
>
> Many systems have been showed to disrespect users’ choice that way.

[Citation needed]

Re: Contradictiory directions

[Óscar Fuentes]

Alexandre Garreau <galex-713@galex-713.eu> writes:

>> > The PCRE and csvtable modules are also in the public domain.
>> > Proprietary versions of them could be created ino the future.
>> 
>> So you just decidead that all those versions that allow to distribute
>> non-free versions of the code are incompatible with the GPL after all?
>> <sigh>
>
> No, but enough for them to *potentially become* so *without being noticed* 
> by emacs or even the users themselves…
>
> …what if one day mac os x or ubuntu or windows starts bundling a version 
> of sqlite with special “improved” extensions that are made proprietary? we 
> don’t want that.  We want emacs to break in that case, and potentially the 
> users to do something to become themselves responsible of a such 
> combination of software.

If the OS starts shipping SQLite with "improved" extensions and Emacs
uses it, it is the same as any other OS-provided library: acceptable by
GNU, although undesirable.

Please note how you do talk about problematic extensions but not about a
problematic OS-provided SQLite shared library. Why are we so concerned
with the possibility of unholy extensions and not so much with the
possibility of an unholy SQLite binary? Because in that case the only
choice is to not use SQLite at all? (and most other Free but not GPL
libraries)

Seriously, let's stop making up dramas based on scenarios disconnected
from reality. The propietary software industry does not give a rat ass
about Emacs and soon it will not give a rat ass about Gcc either,
because there are better *free* alternatives, which arose in great part
thanks to stances like this.

Re: Contradictiory directions

[Stefan Monnier]

> Seriously, let's stop making up dramas based on scenarios disconnected
> from reality.

FWIW I agree about this point.

> ... about Gcc either, because there are better *free* alternatives,
> which arose in great part thanks to stances like this.

But this is a poorly chosen example.  LLVM was developed originally
because it was easier to start from scratch than to evolve an existing
system that had accrued a lot of (necessary) complexity.  Back then it
was mostly a vehicle for academic research and I've never seen any hint
that circumventing the GPL was part of the motivation.

Then it got picked up by companies (mostly Apple) specifically because
it didn't use the GPL, because they did not want to be forced to
released their source code (this can be seen as the price we had to pay
for GCC to get Objective C support, since many years earlier, NeXT was
forced to release their Objective C compiler's source code because it
was built on top of GCC, and Jobs really resented that; it's arguably
also the reason why macOS has switched to Zsh and remained at Emacs-22).

AFAIK the issue with support for plugins only appeared much later.

So in the case of LLVM-vs-GCC, the reason for the heavy investment into
LLVM is not so much the FSF's "stance" on anything, it's an opposition
to the core principle of the GPL.

And oddly enough, last I checked, GCC is still pretty damn competitive
with LLVM, despite all that investment, so "better" is debatable ;-)


        Stefan

Re: Contradictiory directions

[Óscar Fuentes]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

Off-topic, so this will be my last message on this thread.

>> ... about Gcc either, because there are better *free* alternatives,
>> which arose in great part thanks to stances like this.
>
> But this is a poorly chosen example.  LLVM was developed originally
> because it was easier to start from scratch than to evolve an existing
> system that had accrued a lot of (necessary) complexity.  Back then it
> was mostly a vehicle for academic research and I've never seen any hint
> that circumventing the GPL was part of the motivation.

This is mostly true. To the point that the LLVM backend (Clang came much
later) was offered to Gcc.

> Then it got picked up by companies (mostly Apple) specifically because
> it didn't use the GPL, because they did not want to be forced to
> released their source code (this can be seen as the price we had to pay
> for GCC to get Objective C support, since many years earlier, NeXT was
> forced to release their Objective C compiler's source code because it
> was built on top of GCC, and Jobs really resented that; it's arguably
> also the reason why macOS has switched to Zsh and remained at Emacs-22).
>
> AFAIK the issue with support for plugins only appeared much later.
>
> So in the case of LLVM-vs-GCC, the reason for the heavy investment into
> LLVM is not so much the FSF's "stance" on anything, it's an opposition
> to the core principle of the GPL.

This is more complex than you make it appear :-)

> And oddly enough, last I checked, GCC is still pretty damn competitive
> with LLVM, despite all that investment, so "better" is debatable ;-)

The superiority of LLVM/Clang (and all its satellite projects) is in its
focus on technical excellence, on a broad sense: the code not only must
be performant, but clearly written and carefully architected as well.
The social dynamics was more open: broad changes were encouraged, no old
guard vetoing disruptive ideas, enthusiastic and welcoming community
etc. This caused that both the source code and the community appeared
much more attractive to all sorts of contributors, creating an snowball
effect. The openness of the design, which facilitated growing other
projects on top of it, caused a proliferation of academic, hobbist and
industrial derived works. Some of them are closed-source, but many are
not, and even the closed ones show a tendency to open and contribute to
upstream because it reduces costs.

Major Clang/LLVM contributors like Google would have no significant
issue with Gcc being GPL, but LLVM/Clang exists and it is much more easy
to work with (at all levels: technical and social.)

Meanwhile, Gcc was under severe imposed restrictions precisely on the
areas where LLVM/Clang excels. That's no coincidence: there was a demand
for those features. Now the grip over Gcc loosened a bit, but it carries
a rigid and obsolete architecture that will keep it inferior for many
years, if not forever. Any advantage on code generation will be erased,
sooner than later.

Since a few years ago Gcc improved after painfully breaking old
constraints, pressured by the new competitor, but I'm afraid that it
will be too little, too late. Linux compiles with Clang, and that's a
very worrying signal for Gcc, because if certain distributions migrate
to Clang, Gcc development will be over.

Re: Contradictiory directions

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > "Blacklist" and "whitelist" appear in the Emacs source tree a total of
  > 432 times, while "allowlist" and "blocklist" appear a total of 259 times
  > exclusively in the context of mh-e.

In the GNU Project we do not blindly follow "industry standards".  We
think about them and consider following them when that is good for
users.  See node Non-GNU Standards in the GNU Coding Standards.

There is no reason to consider "blacklist" and "whitelist" offensive.
They never had anything to do with race; they don't refer to people.
They use an old metaphor of "black" and "white" standing for "evil"
and "good".

We should not feel obliged to bend over backwards for people who take
offense when none has been given.  We should, however, choose the best
terms.

I think that the best terms are "allowlist" and "blocklist."  They are
best because they make their meanings visible directly -- not via a
metaphor.  Using these names is preferable in new features.

Changing the names used in existing features has more of a cost.  The
incompability may cause trouble, or inconvenence, for users.  I have
no opinion about changing the names in old features.

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: Contradictiory directions

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > These are system libraries, all of which are either free or have free
  > replacements.  I don't think we allow features that depend on
  > proprietary libraries that have no free replacement.  And to distribute
  > a binary of Emacs that links against a non-free non-system library would
  > be illegal.

The GNU GPL has special rules for "system libraries".  The rule is
different in GPL v2 and GPL v3, but the basic point is that they permit
linking any GPL-covered program with limited libraries that come with the
operating system itself.

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: Contradictiory directions

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > >
  > >> Propietary modules can define any symbol, so the
  > >> "this_module_is_fine_with_gnus" or whatever trick is used on Emacs and
  > >> gcc modules is even less of a solution.

I worked this out with a lawyer; it has a legal basis.  Releasing a
nonfree module designed specifically to link with Emacs or GCC is a
GPL violation.  If it defines that special symbol, that give us
evidence that that the module was designed specifically to link
with on of them.

I don't recall more details than that -- the conversation was
many years ago.

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: master 3d38d1d: Add sqlite3 support to Emacs

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > It’s an environment variable making ld.so preload dynamical libraries 
  > before any other, so that you can overwrite any C function with another, 
  > just by specifying a .so library implementing it in that variable.  You 
  > can use that to tweak the behavior of any program.  Lars was using that as 
  > an argument to state it is futile to stop users from running proprietary 
  > software if they want to since they can do it anyway that way.

Indeed, we can't stop users from running nonfree software, or linking
it in with Emacs.  Indeed, the GPL says that end users are allowed to link
Emacs with whatever they wish -- but not distribute those nonfree versions.

We don't want Lisp programs to be able to specify nonfree sqlite3
libraries, because those Lisp programs would be effectively nonfree
extensions to Emacs, but people are likely to believe they are allowed
to distribute them.

There is no obvious perfect place to draw a line, but we must do our
best -- and this is it.

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: master 3d38d1d: Add sqlite3 support to Emacs

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

Thanks for sending me the LD_PRELOAD info.

LD_PRELOAD seems to be a user customization facility, not well suited
to releasing modified versions of programs.

So I think it is not significant for the question of sqlite3 modules.

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: Contradictiory directions

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > Eli and I are the maintainers.

You, Eli and I are the Emacs maintainers.
I've appointed several different Emacs maintainers
over the past 20 years, but I never took myself off the list.

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: master 3d38d1d: Add sqlite3 support to Emacs

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > The use case is to load the pcre module, which will allow us to list
  > stored data based on regexp matches.  I.e., it will give users greater
  > power to inspect .sqlite files.

Would you please tell me more about the PCRE module?
Where is it distributed -- along with sqlite3 itself?

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: Contradictiory directions

[Po Lu]

Richard Stallman <rms@gnu.org> writes:

> [[[ To any NSA and FBI agents reading my email: please consider    ]]]
> [[[ whether defending the US Constitution against all enemies,     ]]]
> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
>
>   > Eli and I are the maintainers.
>
> You, Eli and I are the Emacs maintainers.
> I've appointed several different Emacs maintainers
> over the past 20 years, but I never took myself off the list.

So, who do I listen to..? 

I'm still confused about what to do with `sqlite-load-extension'.

Thanks.

Re: Contradictiory directions

[Alexandre Garreau]

Le merkredo, 15-a de decembro 2021, 19-a horo kaj 4:49 CET Óscar Fuentes a 
écrit :
> Alexandre Garreau <galex-713@galex-713.eu> writes:
> 
> 
> 
> > Le merkredo, 15-a de decembro 2021, 13-a horo kaj 44:48 CET Óscar
> > Fuentes
> > a écrit :
> 
> 
> >> The scenario of someone sneaking in a non-free SQLite extension
> >> against
> >> the user's wishes is a bit far-fetched, to say the least. So we are
> >> wasting a lot of energy worrying about how to effectively
> >> inconvenience
> >> our users for "protecting" them from an unlikely event no matter how
> >> much limitations are imposed on the feature being discussed. I
> >> thought
> >> that the gcc/llvm debacle would be understood at this point.
> 
> 
> 
> > Many systems have been showed to disrespect users’ choice that way.
> 
> [Citation needed]

Well why do you think proprietary platforms avoid the GPL?

it may just as well be because some library is tivoized, or a thing like 
that

Re: Contradictiory directions

[Alexandre Garreau]

Le merkredo, 15-a de decembro 2021, 19-a horo kaj 28:52 CET Óscar Fuentes 
a écrit :
> >> non-free versions of the code are incompatible with the GPL after
> >> all?
> >> <sigh>
> 
> 
> 
> > No, but enough for them to *potentially become* so *without being
> > noticed* by emacs or even the users themselves…
> > 
> > …what if one day mac os x or ubuntu or windows starts bundling a
> > version of sqlite with special “improved” extensions that are made
> > proprietary? we don’t want that.  We want emacs to break in that
> > case, and potentially the users to do something to become themselves
> > responsible of a such combination of software.
> 
> If the OS starts shipping SQLite with "improved" extensions and Emacs
> uses it, it is the same as any other OS-provided library: acceptable by
> GNU, although undesirable.
> 
> Please note how you do talk about problematic extensions but not about a
> problematic OS-provided SQLite shared library. Why are we so concerned
> with the possibility of unholy extensions and not so much with the
> possibility of an unholy SQLite binary? Because in that case the only
> choice is to not use SQLite at all? (and most other Free but not GPL
> libraries)

Indeed, and it was mentioned before, that it would make sense to check for 
the gpl-compatibility symbol inside sqlite as well, since it’s not 
copylefted.

> Seriously, let's stop making up dramas based on scenarios disconnected
> from reality. The propietary software industry does not give a rat ass
> about Emacs

it’s not paranoia about emacs; they could not dare about emacs and yet 
dare about sqlite and not about their users’ freedom; we are emacs and 
want to protect users’ freedom

> and soon it will not give a rat ass about Gcc either,
> because there are better *free* alternatives, which arose in great part
> thanks to stances like this.

gcc and emacs are free, you are talking about free but potentially non-
free alternatives, and the difference is not appealing

Re: master 3d38d1d: Add sqlite3 support to Emacs

[Lars Ingebrigtsen]

Richard Stallman <rms@gnu.org> writes:

> Would you please tell me more about the PCRE module?
> Where is it distributed -- along with sqlite3 itself?

In Debian, at least, it's a separate package.  Let's see...
apt info says:

Maintainer: Gilles Filippini <pini@debian.org>
Homepage: http://git.altlinux.org/people/at/packages/?p=sqlite3-pcre.git

So it sounds like a third party module.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Contradictiory directions

[Eli Zaretskii]

> From: Óscar Fuentes <ofv@wanadoo.es>
> Date: Wed, 15 Dec 2021 22:15:50 +0100
> 
> The superiority of LLVM/Clang (and all its satellite projects) is in its
> focus on technical excellence, on a broad sense: the code not only must
> be performant, but clearly written and carefully architected as well.
> The social dynamics was more open: broad changes were encouraged, no old
> guard vetoing disruptive ideas, enthusiastic and welcoming community
> etc. This caused that both the source code and the community appeared
> much more attractive to all sorts of contributors, creating an snowball
> effect. The openness of the design, which facilitated growing other
> projects on top of it, caused a proliferation of academic, hobbist and
> industrial derived works. Some of them are closed-source, but many are
> not, and even the closed ones show a tendency to open and contribute to
> upstream because it reduces costs.
> 
> Major Clang/LLVM contributors like Google would have no significant
> issue with Gcc being GPL, but LLVM/Clang exists and it is much more easy
> to work with (at all levels: technical and social.)
> 
> Meanwhile, Gcc was under severe imposed restrictions precisely on the
> areas where LLVM/Clang excels. That's no coincidence: there was a demand
> for those features. Now the grip over Gcc loosened a bit, but it carries
> a rigid and obsolete architecture that will keep it inferior for many
> years, if not forever. Any advantage on code generation will be erased,
> sooner than later.
> 
> Since a few years ago Gcc improved after painfully breaking old
> constraints, pressured by the new competitor, but I'm afraid that it
> will be too little, too late. Linux compiles with Clang, and that's a
> very worrying signal for Gcc, because if certain distributions migrate
> to Clang, Gcc development will be over.

That rings a bell: it's what I heard 20 years ago about XEmacs vs GNU
Emacs when I talked (in person) to its main developers.  The rest is
history.

My take from that example is that the factors you mention are somehow
not all that's important for the fate and the future of a large and
flexible software package.  There are other, more important factors
that are left unsaid.

From my POV, GCC is a better compiler, by a large measure, for
languages that I use and on platforms that I care about.  As a user of
a compiler, I don't care about its architecture, I care about its
features, its usefulness during development, and the code it produces.
And Clang is way behind on these, from my POV.  And don't get me
started on other LLVM members, like the debugger.

Re: Contradictiory directions

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: Lars Ingebrigtsen <larsi@gnus.org>,  eliz@gnu.org,
>   stefankangas@gmail.com,  emacs-devel@gnu.org
> Date: Thu, 16 Dec 2021 12:44:02 +0800
> 
> Richard Stallman <rms@gnu.org> writes:
> 
> > [[[ To any NSA and FBI agents reading my email: please consider    ]]]
> > [[[ whether defending the US Constitution against all enemies,     ]]]
> > [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
> >
> >   > Eli and I are the maintainers.
> >
> > You, Eli and I are the Emacs maintainers.
> > I've appointed several different Emacs maintainers
> > over the past 20 years, but I never took myself off the list.
> 
> So, who do I listen to..? 

When the maintainers disagree among them, you should wait for them to
get their act together and make a common decision on the course of
action.

> I'm still confused about what to do with `sqlite-load-extension'.

For now, nothing.  Not as long as the disagreement is not resolved.

IOW, it isn't your problem for now.  It's ours.

Re: master 3d38d1d: Add sqlite3 support to Emacs

[tomas]

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

On Wed, Dec 15, 2021 at 11:41:07PM -0500, Richard Stallman wrote:
> [[[ To any NSA and FBI agents reading my email: please consider    ]]]
> [[[ whether defending the US Constitution against all enemies,     ]]]
> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
> 
> Thanks for sending me the LD_PRELOAD info.
> 
> LD_PRELOAD seems to be a user customization facility,

It definitely is: for the user/sysadmin. Much akin to advice in the
Emacs world. Releasing packages which make use of it has a confusion
potential and should be avoided, unless that is their specific purpose
(example: apulse makes use of LD_PRELOAD to make applications think they
are talking to pulseaudio, whereas the user only has ALSA available [1],
but that is its stated intention; another good example is faketime,
which uses LD_PRELOAD to intercept system calls to control the date/time
an application "sees" -- be it for testing or for reproducible builds).

Definitely not a thing which should happen without the user's knowledge:
she'll be confronted with difficult-to-debug situations otherwise.

> not well suited to releasing modified versions of programs.

Absolutely.

> So I think it is not significant for the question of sqlite3 modules.

Strong agreement here.

Cheers
-- 
tomás

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: master 3d38d1d: Add sqlite3 support to Emacs

[tomas]

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

On Wed, Dec 15, 2021 at 11:41:08PM -0500, Richard Stallman wrote:
> [[[ To any NSA and FBI agents reading my email: please consider    ]]]
> [[[ whether defending the US Constitution against all enemies,     ]]]
> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
> 
>   > The use case is to load the pcre module, which will allow us to list
>   > stored data based on regexp matches.  I.e., it will give users greater
>   > power to inspect .sqlite files.
> 
> Would you please tell me more about the PCRE module?
> Where is it distributed -- along with sqlite3 itself?

PCRE ("Perl Compatible Regular Expressions") is a C library written by
Philip Hazel (founding author of the Exim mail server). I think it was
originally written to have some more expressive "regular" [1] expressions
in Exim itself, but showed some worth as an independent library, so it
was released as such, under the BSD, to encourage use (Exim is GPLV2).

It tries to be compatible to Perl's regular expression machinery; it is
used in many systems, among other PHP, R, PostgreSQL.

There is a (not javascript-crippled, yay!) website at
https://www.pcre.org/. Distribution is via github, alas.

Cheers

[1] All those go beyond strict regular expressions, in the strict sense
   of the Chomsky hierarchy.

-- 
t

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: Contradictiory directions

[tomas]

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

On Thu, Dec 16, 2021 at 09:13:19AM +0200, Eli Zaretskii wrote:

[...]

> > Since a few years ago Gcc improved after painfully breaking old
> > constraints, pressured by the new competitor, but I'm afraid that it
> > will be too little, too late. Linux compiles with Clang, and that's a
> > very worrying signal for Gcc, because if certain distributions migrate
> > to Clang, Gcc development will be over.
> 
> That rings a bell: it's what I heard 20 years ago about XEmacs vs GNU
> Emacs when I talked (in person) to its main developers.  The rest is
> history.

I think it is still relevant. Big corps have learnt to ride the waves
since then. Watch Microsoft "being friendly" to "open source" to the
tune of $ 7 billion (if I remember correctly) they shelled out for
Github (they didn't out of the goodness and warmth of their hearts:
I, at least, don't believe in fairy tales). Watch Google (before that)
editing out the "do no evil" while nobody seemed to be looking.

They still want some kind of user [1] control, but they know they can't
be as ham-fisted as they used to be in the '8ies and '90ies. The
question is wheter to agree or disagree with this "new" user control
patterns. Personally I don't, but I don't yet know the FSF's position on
that.

Cheers

[1] how is the return on investment to be secured, otherwise?

-- 
t

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: Contradictiory directions

[Eli Zaretskii]

> Date: Thu, 16 Dec 2021 10:41:01 +0100
> Cc: Óscar Fuentes <ofv@wanadoo.es>, emacs-devel@gnu.org
> From:  <tomas@tuxteam.de>
> 
> > That rings a bell: it's what I heard 20 years ago about XEmacs vs GNU
> > Emacs when I talked (in person) to its main developers.  The rest is
> > history.
> 
> I think it is still relevant. Big corps have learnt to ride the waves
> since then.

Nothing new here: XEmacs started because a certain company wanted to
make profits from it, and was unhappy with the pace and directions of
the Emacs development.

> They still want some kind of user [1] control, but they know they can't
> be as ham-fisted as they used to be in the '8ies and '90ies.

If you pay too much attention to details, you can never learn from
past experience, because there's no exact repetition of precisely the
same circumstances.  Which details are important and which aren't is a
non-trivial judgment call, and I guess we differ in how we make that
call.  Which might mean you are right and I'm wrong, of course.

However, my point was that Óscar approaches the issue in a too
simplistic way (if I take what he wrote as the description of his
approach), and that there's more here than meets the eye.

Re: Contradictiory directions

[Dmitry Gutov]

On 16.12.2021 10:13, Eli Zaretskii wrote:

>  From my POV, GCC is a better compiler, by a large measure, for
> languages that I use and on platforms that I care about.  As a user of
> a compiler, I don't care about its architecture, I care about its
> features, its usefulness during development, and the code it produces.
> And Clang is way behind on these, from my POV.  And don't get me
> started on other LLVM members, like the debugger.

All popular code assistance tools use Clang (code completion, 
navigation, etc). Even people who will deploy with GCC, if they want 
completion, have to install Clang.

And it's catching up performance-wise.

If that doesn't worry you, it should.

Re: Contradictiory directions

[Eli Zaretskii]

> Cc: emacs-devel@gnu.org
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Thu, 16 Dec 2021 14:01:32 +0300
> 
> On 16.12.2021 10:13, Eli Zaretskii wrote:
> 
> >  From my POV, GCC is a better compiler, by a large measure, for
> > languages that I use and on platforms that I care about.  As a user of
> > a compiler, I don't care about its architecture, I care about its
> > features, its usefulness during development, and the code it produces.
> > And Clang is way behind on these, from my POV.  And don't get me
> > started on other LLVM members, like the debugger.
> 
> All popular code assistance tools use Clang (code completion, 
> navigation, etc). Even people who will deploy with GCC, if they want 
> completion, have to install Clang.
> 
> And it's catching up performance-wise.
> 
> If that doesn't worry you, it should.

I was talking about the compiler, not the tools you mention.

Re: Contradictiory directions

[Dmitry Gutov]

On 16.12.2021 14:08, Eli Zaretskii wrote:
>> Cc:emacs-devel@gnu.org
>> From: Dmitry Gutov<dgutov@yandex.ru>
>> Date: Thu, 16 Dec 2021 14:01:32 +0300
>>
>> On 16.12.2021 10:13, Eli Zaretskii wrote:
>>
>>>   From my POV, GCC is a better compiler, by a large measure, for
>>> languages that I use and on platforms that I care about.  As a user of
>>> a compiler, I don't care about its architecture, I care about its
>>> features, its usefulness during development, and the code it produces.
>>> And Clang is way behind on these, from my POV.  And don't get me
>>> started on other LLVM members, like the debugger.
>> All popular code assistance tools use Clang (code completion,
>> navigation, etc). Even people who will deploy with GCC, if they want
>> completion, have to install Clang.
>>
>> And it's catching up performance-wise.
>>
>> If that doesn't worry you, it should.
> I was talking about the compiler, not the tools you mention.

I'm talking about the compiler and the related infrastructure. The tools 
reuse parts of the compiler.

When a small development team (for example) has to use both compilers to 
do their work, it will be only natural that they try to remove one of 
them from the equation. And they won't be able to remove Clang, for the 
reason above.

Re: Contradictiory directions

[tomas]

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

On Thu, Dec 16, 2021 at 12:09:48PM +0200, Eli Zaretskii wrote:
> > Date: Thu, 16 Dec 2021 10:41:01 +0100
> > Cc: Óscar Fuentes <ofv@wanadoo.es>, emacs-devel@gnu.org
> > From:  <tomas@tuxteam.de>
> > 
> > > That rings a bell: it's what I heard 20 years ago about XEmacs vs GNU
> > > Emacs when I talked (in person) to its main developers.  The rest is
> > > history.
> > 
> > I think it is still relevant. Big corps have learnt to ride the waves
> > since then.
> 
> Nothing new here: XEmacs started because a certain company wanted to
> make profits from it, and was unhappy with the pace and directions of
> the Emacs development.

I remember well, I'm /that/ old :)

> > They still want some kind of user [1] control, but they know they can't
> > be as ham-fisted as they used to be in the '8ies and '90ies.
> 
> If you pay too much attention to details, you can never learn from
> past experience, because there's no exact repetition of precisely the
> same circumstances.

I'm not advocating that. I'm just pointing out that the strategy has
become "softer". For example, someone pointed out that Google doesn't
avoid the GPL. They do (especially V3), but in a less aggressive way.

>                     Which details are important and which aren't is a
> non-trivial judgment call, and I guess we differ in how we make that
> call.  Which might mean you are right and I'm wrong, of course.

I think everyone is wrong, in a different way :-)

> However, my point was that Óscar approaches the issue in a too
> simplistic way (if I take what he wrote as the description of his
> approach), and that there's more here than meets the eye.

Agreed on this, definitely.

Cheers
-- 
tomás

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: Contradictiory directions

[Andrea Corallo]

Richard Stallman <rms@gnu.org> writes:

> [[[ To any NSA and FBI agents reading my email: please consider    ]]]
> [[[ whether defending the US Constitution against all enemies,     ]]]
> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
>
>   > Eli and I are the maintainers.
>
> You, Eli and I are the Emacs maintainers.
> I've appointed several different Emacs maintainers
> over the past 20 years, but I never took myself off the list.

On this subject I think would be very helpful to have head maintainers
listed into the MAINTAINERS file (similarly to other projects like GCC).

I must admit when I approached Emacs development I wasn't sure about who
currently carried this role, and apparently I'm not the only one.

At the time the only information I found about who were the current
maintainers was [1], but apparently that is inaccurate.

Best Regards

  Andrea

[1] <https://directory.fsf.org/wiki/Emacs#tab=Details>

Re: Contradictiory directions

[Eli Zaretskii]

> From: Andrea Corallo <akrl@sdf.org>
> Cc: Lars Ingebrigtsen <larsi@gnus.org>, luangruo@yahoo.com, eliz@gnu.org,
>         stefankangas@gmail.com, emacs-devel@gnu.org
> Date: Thu, 16 Dec 2021 13:39:24 +0000
> 
> > You, Eli and I are the Emacs maintainers.
> > I've appointed several different Emacs maintainers
> > over the past 20 years, but I never took myself off the list.
> 
> On this subject I think would be very helpful to have head maintainers
> listed into the MAINTAINERS file (similarly to other projects like GCC).

Our MAINTAINERS has a different purpose.

Re: Contradictiory directions

[Andrea Corallo]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Andrea Corallo <akrl@sdf.org>
>> Cc: Lars Ingebrigtsen <larsi@gnus.org>, luangruo@yahoo.com, eliz@gnu.org,
>>         stefankangas@gmail.com, emacs-devel@gnu.org
>> Date: Thu, 16 Dec 2021 13:39:24 +0000
>> 
>> > You, Eli and I are the Emacs maintainers.
>> > I've appointed several different Emacs maintainers
>> > over the past 20 years, but I never took myself off the list.
>> 
>> On this subject I think would be very helpful to have head maintainers
>> listed into the MAINTAINERS file (similarly to other projects like GCC).
>
> Our MAINTAINERS has a different purpose.

Maybe could/should also have the purpose of listing head maintainers?

But anyway I think that, regardless where, would be helpful to have a
place somewhere to do that.

Best Regards

  Andrea

Re: Contradictiory directions

[Arthur Miller]

<tomas@tuxteam.de> writes:

> On Thu, Dec 16, 2021 at 09:13:19AM +0200, Eli Zaretskii wrote:
>
> [...]
>
>> > Since a few years ago Gcc improved after painfully breaking old
>> > constraints, pressured by the new competitor, but I'm afraid that it
>> > will be too little, too late. Linux compiles with Clang, and that's a
>> > very worrying signal for Gcc, because if certain distributions migrate
>> > to Clang, Gcc development will be over.
>> 
>> That rings a bell: it's what I heard 20 years ago about XEmacs vs GNU
>> Emacs when I talked (in person) to its main developers.  The rest is
>> history.
>
> I think it is still relevant. Big corps have learnt to ride the waves
> since then. Watch Microsoft "being friendly" to "open source" to the
> tune of $ 7 billion (if I remember correctly) they shelled out for
> Github (they didn't out of the goodness and warmth of their hearts:
> I, at least, don't believe in fairy tales). Watch Google (before that)
> editing out the "do no evil" while nobody seemed to be looking.

Money is in another place nowadays. It's not in the software they sell to users,
it's users they sell nowdays, or at least data they gather from users. I
wouldn't be surprised if they even give away OS for "free" one day; they already
do for the most part, just as they did with IE and other software, just so
people use it, or if they even go "open source" with it in some forseable
future; not a year or so, but 10? 15? Maybe sooner, when they can't sell it any
more; when new generation used to Android/iOS and gnu/Linux have grown up so
they don't care about MS Windows any more?

MS clearly had a vision (business plan) when they purchased Github and that AI
company and when they started VS Code. It took several years for outside world
to realize, but I think it is clear now, with codepilot. They want users, they
want people to create content on their platform, because people are money, not
the software they (micorosoft) create. They failed with Bing, but I think Github
+ AI company is their "Google search".

Re: Contradictiory directions

[tomas]

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

On Thu, Dec 16, 2021 at 03:18:55PM +0100, Arthur Miller wrote:
> <tomas@tuxteam.de> writes:

> Money is in another place nowadays. It's not in the software they sell to users,
> it's users they sell nowdays, or at least data they gather from users. I
> wouldn't be surprised if they even give away OS for "free" one day
> [...]

Google is doing /exactly/ that. With two offers (so-far): Android and
ChromeOS.

Cheers
-- 
tomás

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: Contradictiory directions

[Stephen Leake]

Po Lu <luangruo@yahoo.com> writes:

> <tomas@tuxteam.de> writes:
>
>> This is a politically loaded discussion. Still, I think it is important.
>> If there is a reason to assume that "blacklist"/"whitelist" might offend
>> some people, I think it does make sense to look for alternatives.

+1

> There is a node "Other Politics" in the Information for Maintainers of
> GNU Software, which says:
>
>   A GNU package should not seriously advocate any other political
>   causes.  Not that the GNU Project opposes those other causes.  Rather,
>   it is neutral on them, and GNU packages should be neutral too.

No one can be completely neutral; we always bring our personal history
with us. When that history includes systemic problems, we are often
unconscious of the impact of our actions.

In addition "neutral" is not the same as "ignore the issue", and "use
new terms" is not the same as "advocate".

We recently agreed to use the term "main" instead of "master" for a Gnu
ELPA repostory, for similar reasons.

-- 
-- Stephe

Re: Contradictiory directions

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > That sounds like defeatism.  Whether or not it will work, we are going
  > to try, and when we discover a problem, we are going to try to solve it
  > the best way we can.

That is very well put.  We. the GNU Project, deal with such situations
that way.  The free software movement is a fight against the injustice
of nonfree software, and we take it seriously.

  > See https://www.gnu.org/philosophy/compromise.html.

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: Contradictiory directions

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

Would people please move the discussion of GCC and LLVM to the
emacs-tangents list?

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: master 3d38d1d: Add sqlite3 support to Emacs

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]


  > Maintainer: Gilles Filippini <pini@debian.org>
  > Homepage: http://git.altlinux.org/people/at/packages/?p=sqlite3-pcre.git

  > So it sounds like a third party module.

Perhaps we should package this with Emacs so as to assure every
Emacs installation has the real PCRE.


-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: master 3d38d1d: Add sqlite3 support to Emacs

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

I wrote

    Perhaps we should package this with Emacs so as to assure every
    Emacs installation has the real PCRE.

This is one part of a nest of serious issues.  How will we
expect/tell users to find sqlite3 plug-ins for use in Emacs -- for
instance, PCRE?

1. Do free GNU/Linux distros package it?  If so, with sqlite3 or separately?

2. What about people who aren't using one of those distros,
or are not using GNU/Linux?  Where would they get these?

3. Does that involve looking in package repos that contain
nonfree plug-ins too?

4. What does the sqlite3 package itself say about where to get plug-ins?
Does it direct people to a place with nonfree plug-ins?

"How do we tell users to find sqlite3 plug-ins for use in Emacs?" is a
question that will be certainly have a factual answer.  If we don't
choose it, other people's choices plus happenstance will choose it.

So if we are going to include sqlite3 in Emacs, we had better choose
a good answer for this question.






-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: master 3d38d1d: Add sqlite3 support to Emacs

[Eli Zaretskii]

> From: Richard Stallman <rms@gnu.org>
> Date: Sat, 18 Dec 2021 23:57:13 -0500
> Cc: andrewjmoreton@gmail.com, emacs-devel@gnu.org
> 
>     Perhaps we should package this with Emacs so as to assure every
>     Emacs installation has the real PCRE.
> 
> This is one part of a nest of serious issues.  How will we
> expect/tell users to find sqlite3 plug-ins for use in Emacs -- for
> instance, PCRE?

As with optional libraries, this information is usually in README and
INSTALL.  And the configure script checks more precise requirements,
if there are any, for including optional libraries in the build.

> 1. Do free GNU/Linux distros package it?  If so, with sqlite3 or separately?

Here's a page that describes how to install the PCRE plug-in on
Ubuntu:

  https://zoomadmin.com/HowToInstall/UbuntuPackage/sqlite3-pcre

According to that page, Ubuntu does provide a package for it.

> 2. What about people who aren't using one of those distros,
> or are not using GNU/Linux?  Where would they get these?

The code can be easily found by searching the Internet, and our
README/INSTALL should include the canonical URL.

Re: Contradictiory directions

[tomas]

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

On Thu, Dec 16, 2021 at 09:45:43AM -0800, Stephen Leake wrote:

[...]

> No one can be completely neutral; we always bring our personal history
> with us [...]

I tend to put it (with a bit of tongue-in-cheek) like so: saying "I'm
neutral" is just a short way of saying "I currently can't see my bias".

Having some grounding there, I think the most important point in science
is a long and skillful fight to "see" one's biases and take them into
account. Read on "personal equation" [1]. Take it as a metaphor or as a
case study. Or as a reminder that humility is essential in growing one's
knowledge. Or just as a fetching story on some important steps in
science. For me, it's "all of the above", but I might be biased :)

Cheers

[1] https://en.wikipedia.org/wiki/Personal_equation

-- 
tomás

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: Contradictiory directions

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

You're entitled to have a political preference about the name for the
principal branch in a repo, but the GNU Project takes a firmly neutral
stance on the matter.

The GNU Project is dedicated to the cause of software freedom.  We
also defend basic human rights, such as freedom of speech.  (If Emacs
design decisions could actually free slaves, that would be an
important design consideration, but they can't.)  Other political
issues are unrelated and extraneous.

As you said, being neutral on a political issue does not mean simply
disregarding it.  Our neutrality on extraneous issues is an active
stance.  It means that participants who have views on unrelated
political issues should not try to argue about them here.

One general fact about those political issues is that people disagree
on them.  We want people with various views to be welcome to
participate in GNU development.  Participants must not argue about
extraneous issues; and especially they must not try to pressure the
rest of us into yieldihg.  That is way, way beyond the line.

You can advocate your views on unrelated political issues in the rest
of your life -- we all can.  Outside, we may agree on some extraneous
issues while clashing on other extraneous issues.  Please don't bring
those disagreements in here.

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)