Re: as for Calc and the math library

[Eli Zaretskii <eliz@gnu.org>]

> From: arthur miller <arthur.miller@live.com>
> CC: "emacs-devel@gnu.org" <emacs-devel@gnu.org>
> Date: Tue, 13 Aug 2024 07:16:35 +0000
> 
> > > Eli Zaretskii <eliz@gnu.org> writes:
> > >
> > > > We made the effort to allow loading dynamic modules precisely for this
> > > > reason: to allow free libraries to be used, but not non-free ones.
> 
> Emacs users are "linking" Emacs to all kind of proprietary, non-free services
> these days. You are reading /r/Emacs yourself and seen packages popping up
> targeting this or that proprietary service almost every day. Shared libraries
> are no longer the staple of distributing closed source. The computing landscape
> has change a lot since 1980s/1990s.
> 
> > > You absolutely can use non-free dynamic modules: enforcing the existence
> > > of a symbol saying "I promise I'm free" does not change anything. One
> > > could also easily add a free dynamic module that calls non-free
> > > libraries.
> >
> > The need to declare that a library is free and have its sources freely
> > available does serve as an obstacle for non-free software.  And using
> > non-free library with a free module is against the GPL, so it is
> > illegal.  We cannot prevent people from lying and doing illegal
> > things, we can only make it harder.
> 
> IMO, licenses are to restrict the usage, not arbitrary technical
> limitations. We could similary have a token declaration in FFI interface, when
> loading a library, no? 

You are basically reiterating what Nicolas already said, and I
answered that.  I see no reason to repeat my answers to these
arguments, they are still the same.

> You are preventing  people not familiar with programming who can't write a
> simple C wrapper to load a proprietary library, but it ain't stop any malicious
> company anyway.

People not familiar with programming will be unable to use FFI for
anything serious anyway.

> At the same time, the strategy is slowing down
> Emacs development and make it harder for talented people to actually write
> useful code for Emacs. It is also growing the C core unnecessary. 

I don't share this view of the Emacs development, of course.  And with
all due respect, I don't think you are in a good position to judge
that: you are not involved in this deep enough and long enough to have
the perspective and experience to make such judgments.

> There is a plethora of MIT licensed math libraries, with big API surfaces, 
> well optimized for many architectures which users could bring into Emacs
>  themselves.

AFAIU, there should be no reasons not to be able to load MIT licensed
libraries via the emacs-module machinery.

> Anyway, Guile is the "gnu extension language", and there are no
> problems to expose FFI:
> 
> https://www.gnu.org/software/guile/manual/html_node/Foreign-Function-Interface.html
> 
> How come there is no decision against loading shared objects in Guile? There was
> even a discussion, on this very mailing list, of Emacs core re-written in Guile
> (which seems to not happen). That would auto-expose Guile FFI, but that seemed
> to be OK?
> 
> Similar for CLisp and GCL, both are GNU projects and expose FFI.

These questions are not for me to answer.  I'm not responsible for
these other projects.  I think they are mistaken, but then the Guile
folks never listened to what I had to say on quite a few subjects, so
I'm not surprised.  (I know nothing about how Common Lisp is developed
and what are its goals.)

For the record: there are other GNU projects that use the same
"restrictions" on plugins: Gawk, GNU Make, and GCC, to mention those I
know about.  So it isn't like Emacs is alone in this.