>> > > Specifically, modify the `define-ffi-library' macro that emacs-ffi
>> > > provides.
>> > >
>> > > Presently, it takes two arguments: a SYMBOL and a NAME. I am proposing
>> > > that it be updated to take three arguments: a SYMBOL, a NAME and a
>> > > GPL-COMPATIBLE-P token. A value of `t' would be necessary for creating
>> > > a reference to the library.
>> >
>> > And if the value is not t, then the load will fail? If so, then this
>> > additional argument makes very little sense: you could instead say
>>
>> It makes as much sense as it makes in C library. The token is basically an
>> agreement between Emacs developers and the user not to load (link) closed
>> source libraries into Emacs.
>
>No. What we need is the declaration _by_the_library_ being loaded
>that it complies. It is not an agreement between Emacs and the
>library, it's a _requirement_ on our part that only the library itself
>can fulfill.
I have seen your previous answers to others, and I do understand the point you
make, but I think the argument fails because a module can be just a proxy to a
non-free library. If I can put it in other words, I wonder if it is a "false
sense of security", because it is a guarantee by the person who writes the C
module, not the 3rd party library they link to. Of course they are violating the
license if they link to a non-free library, but that we are agreeing about we
can't prevent.
>> > that just by loading the library, the Lisp program which uses
>> > emacs-ffi "declares" the loaded library to be GPL-compatible. And we
>> > are back where we began.
>>
>> Yes, you could. It would just completely remove the barrier. However,
>> the token is an explicit acknowledgment of Emacs policy and license terms, by
>> the person who loads the library into Emacs.
>
>No, see above.
>
>> > The way we do it when loading modules requires the _loaded_ library to
>> > declare itself compatible, by exporting a symbol of a certain name.
>> > That is an action by the library we load, not by the Lisp program
>> > which loads it.
>>
>> True. But as you said yourself, a malicious user can easily cicrumvent it,
>> even
>> in C and there is nothing we can do to prevent them other than possibly taking
>> legal actions against them.
>
>Malicious agents can do all kinds of bad and even unlawful things, but
>we are not under any obligations to cater to them. They can always
>change the Emacs source code to do whatever they like, but why do you
Exactly.
>expect _us_ to do it for them, or make it easier for them to do it?
No, of course I don't expect that from you. My point was (is?) that it is a
trade-off between convinience for Emacs users who would use it as intendended,
only with free software, vs the inconvience it causes.
If you look at some other projects which are more interesting than Emacs to use
as front-ends for non-free software, do we see influx of companies misusing
them? I am thinking of Gtk, KDE/Gnome libs and Libre/OpenOffice for example. All
of those projects could be used to plug-in proprietary software, yet, there are
not so many cases, if any? Even Qt which comes as a dual licensed does not seem
to be misused that way. Perhaps I am just uninformed?
You have mentioned llvm, but I am not familiar enough with them. As I understand
they are financied by Apple, Nvidia and few other big tech companies with
explicit goal to have an alternative to GCC just for the more permissive
licensing.
>> If some company or a state would use Emacs or any other GNU program, as a
>> front-end to closed-source software, there is very little one can do
>> technically. It is only the license and the agreement that actually protects
>> it.
>
>That's a separate issue, although it could be related. What is at
>stake here is the fact that we don't want to encourage use of Emacs as
>such a front-end. That policy of the project is not new, it has many
>different expressions, as already mentioned in this thread. We don't
>mention non-free software or fonts in our documentation, we don't
>install changes that specifically favor or are designed to support
>non-free programs, we don't link against non-free libraries except if
>they are system libraries, we don't install functionality enhancements
>on non-free systems if there's no equivalent on free systems, etc.
>etc. So I wonder what is this particular fuss all about. Its
I said it in the beginning: sometimes it is useful to revisit policies
when circumstancies have changed.
>only effect is to waste maintainers' time and energy on replying to
>these posts, and I very much doubt this was the intent. So could we
Have I ever trolled you before? Why would I want to waste your time and energy?
I am certainly the last person in the world to do that, and you should know that.
I understand it takes time and energy, and I appologize for that, but it is
useful to learn why you consider FFI unnaceptable, and to hear the arguments
from the first hand. For the record: I have never brought up this issue before.
>please stop this Nth instance of the same discussions? I cannot
>change the project policies even if I wanted, because I promised to
>uphold them when Richard nominated me.
I wouldn't expect you to change policy on your own neither. I did hope for RMS,
you and other experienced developers to perhaps take a look at the history,
perhaps at other software and how Emacs development could be, and reflect over
the policy if it is still worth keeping or perhaps it can be changed.
Från: Eli Zaretskii <eliz@gnu.org>
Skickat: den 15 augusti 2024 09:02
Till: arthur miller <arthur.miller@live.com>
Kopia: suhailsingh247@gmail.com <suhailsingh247@gmail.com>; gerd.moellmann@gmail.com <gerd.moellmann@gmail.com>; 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: "gerd.moellmann@gmail.com" <gerd.moellmann@gmail.com>, "nicolas@n16f.net"
> <nicolas@n16f.net>, "emacs-devel@gnu.org" <emacs-devel@gnu.org>
> Date: Thu, 15 Aug 2024 05:00:06 +0000
>
> > > Specifically, modify the `define-ffi-library' macro that emacs-ffi
> > > provides.
> > >
> > > Presently, it takes two arguments: a SYMBOL and a NAME. I am proposing
> > > that it be updated to take three arguments: a SYMBOL, a NAME and a
> > > GPL-COMPATIBLE-P token. A value of `t' would be necessary for creating
> > > a reference to the library.
> >
> > And if the value is not t, then the load will fail? If so, then this
> > additional argument makes very little sense: you could instead say
>
> It makes as much sense as it makes in C library. The token is basically an
> agreement between Emacs developers and the user not to load (link) closed
> source libraries into Emacs.
No. What we need is the declaration _by_the_library_ being loaded
that it complies. It is not an agreement between Emacs and the
library, it's a _requirement_ on our part that only the library itself
can fulfill.
> > that just by loading the library, the Lisp program which uses
> > emacs-ffi "declares" the loaded library to be GPL-compatible. And we
> > are back where we began.
>
> Yes, you could. It would just completely remove the barrier. However,
> the token is an explicit acknowledgment of Emacs policy and license terms, by
> the person who loads the library into Emacs.
No, see above.
> > The way we do it when loading modules requires the _loaded_ library to
> > declare itself compatible, by exporting a symbol of a certain name.
> > That is an action by the library we load, not by the Lisp program
> > which loads it.
>
> True. But as you said yourself, a malicious user can easily cicrumvent it, even
> in C and there is nothing we can do to prevent them other than possibly taking
> legal actions against them.
Malicious agents can do all kinds of bad and even unlawful things, but
we are not under any obligations to cater to them. They can always
change the Emacs source code to do whatever they like, but why do you
expect _us_ to do it for them, or make it easier for them to do it?
> If some company or a state would use Emacs or any other GNU program, as a
> front-end to closed-source software, there is very little one can do
> technically. It is only the license and the agreement that actually protects it.
That's a separate issue, although it could be related. What is at
stake here is the fact that we don't want to encourage use of Emacs as
such a front-end. That policy of the project is not new, it has many
different expressions, as already mentioned in this thread. We don't
mention non-free software or fonts in our documentation, we don't
install changes that specifically favor or are designed to support
non-free programs, we don't link against non-free libraries except if
they are system libraries, we don't install functionality enhancements
on non-free systems if there's no equivalent on free systems, etc.
etc. So I wonder what is this particular fuss all about. Its
only effect is to waste maintainers' time and energy on replying to
these posts, and I very much doubt this was the intent. So could we
please stop this Nth instance of the same discussions? I cannot
change the project policies even if I wanted, because I promised to
uphold them when Richard nominated me.