Sv: as for Calc and the math library

[arthur miller <arthur.miller@live.com>]

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

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

Just justifiying the statement that Emacs could have something similar as
GPL_COMPATIBLE token in Lisp API, just as there is in module API. I don't
 think I have seen anyone suggesting that before, at least not what I know of.

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

I think you have misunderstand what I am saying: my point was that this
situation is making it more tedious for experienced people to work with Emacs
while possibly being a stopper *only* for unexperienced programmers.

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

Sure, I certainly am not experienced nor involved in Emacs as long and
as much as you or many others here.

However, I think everyone understands possible fears of a company, or even
just individuals loading proprietary libraries, which free world (GNU) does not
want to endorse and promote such usage. I don't even disagree that it is unjustified.

However, pragmatically, I don't think putting an obstacle is the best way. On the
 contrary, I think, making it as easy as possible to use and extend Emacs for
 whichever purpose, gives a positive incentive for people to see qualities in Emacs
 in particular, and implicitly in GNU project.

As with every important decision, there is a balance between the gain and the
damage. In this case, considering how easy is to work with C libraries in some
other Lisp implementations, and how faster it would be to write extensions and
experiment with Emacs, the gain is perhaps bigger than the possible loss.

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

Nobody is stopping anyone to implement anything as modules, outside of Emacs
core, and I didn't say anything against modules either. I just say FFI would
make it easier and faster.

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

Of course you are not responsible for other projects, nobody thinks you are. My
point is that it is not unthinkable for a GNU project to implement FFI. Also, we
are not directly seeing commercial companies running toward Guile and linking
bunch of proprietary binaries into Guile runtime, and Guile is de facto, a
popular Scheme implementation.

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

I am not sure if it is relevant with non-lisp projects. There are lots of
projects with different needs, some are less, others are more self-contained. It
all depends how the software is used. Lisp(s), Emacs Lisp included, are usually
in somewhat special situation of being relatively isolated islands when it comes
to available software. Common Lisp perhaps being a biggest exception there.
An easy to use FFI makes it easier to take advantage of already existing software,
such as mathematical libraries for example.

Anyway, thanks for the arguments; I think it is useful to re-think the arguments,
regardless on which side of the arguments I am.

best regards
________________________________
Från: Eli Zaretskii <eliz@gnu.org>
Skickat: den 13 augusti 2024 14:12
Till: arthur miller <arthur.miller@live.com>
Kopia: nicolas@n16f.net <nicolas@n16f.net>; emacs-devel@gnu.org <emacs-devel@gnu.org>
Ämne: Re: as for Calc and the math library

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

[-- Attachment #2: Type: text/html, Size: 27709 bytes --]