From: Eli Zaretskii <eliz@gnu.org>
To: arthur miller <arthur.miller@live.com>
Cc: suhailsingh247@gmail.com, gerd.moellmann@gmail.com,
nicolas@n16f.net, emacs-devel@gnu.org
Subject: Re: as for Calc and the math library
Date: Thu, 15 Aug 2024 10:02:11 +0300 [thread overview]
Message-ID: <861q2q8e18.fsf@gnu.org> (raw)
In-Reply-To: <DU2PR02MB10109A727479A59356BA7BCB196802@DU2PR02MB10109.eurprd02.prod.outlook.com> (message from arthur miller on Thu, 15 Aug 2024 05:00:06 +0000)
> 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.
next prev parent reply other threads:[~2024-08-15 7:02 UTC|newest]
Thread overview: 88+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-08-12 5:30 as for Calc and the math library arthur miller
2024-08-12 11:00 ` Eli Zaretskii
2024-08-12 11:23 ` Nicolas Martyanoff
2024-08-12 11:46 ` Eli Zaretskii
2024-08-12 12:11 ` Nicolas Martyanoff
2024-08-12 13:22 ` Eli Zaretskii
2024-08-12 13:38 ` Christopher Dimech
2024-08-15 1:59 ` Richard Stallman
2024-08-15 3:06 ` Christopher Dimech
2024-08-15 6:43 ` Eli Zaretskii
2024-08-15 13:28 ` Christopher Dimech
2024-08-15 16:39 ` Eli Zaretskii
2024-08-13 7:16 ` Sv: " arthur miller
2024-08-13 12:12 ` Eli Zaretskii
2024-08-13 13:10 ` Nicolas Martyanoff
2024-08-13 13:30 ` Eli Zaretskii
2024-08-13 13:48 ` Nicolas Martyanoff
2024-08-13 21:43 ` Sv: " arthur miller
2024-08-14 5:09 ` Eli Zaretskii
2024-08-14 8:45 ` Sv: " arthur miller
2024-08-14 9:56 ` Nicolas Martyanoff
2024-08-14 10:43 ` Eli Zaretskii
2024-08-13 5:39 ` Gerd Möllmann
2024-08-14 4:11 ` Gerd Möllmann
2024-08-14 6:23 ` Eli Zaretskii
2024-08-14 6:28 ` Gerd Möllmann
2024-08-14 6:43 ` Eli Zaretskii
2024-08-14 14:00 ` Suhail Singh
2024-08-14 14:20 ` Eli Zaretskii
2024-08-14 15:08 ` Suhail Singh
2024-08-14 15:31 ` Eli Zaretskii
2024-08-14 16:00 ` Suhail Singh
2024-08-14 16:24 ` Eli Zaretskii
2024-08-14 20:35 ` Emanuel Berg
2024-08-15 5:00 ` Sv: " arthur miller
2024-08-15 7:02 ` Eli Zaretskii [this message]
2024-08-15 20:09 ` arthur miller
2024-08-16 5:47 ` Eli Zaretskii
2024-08-16 6:17 ` we need *modularity* [last problem] (was: Re: as for Calc and the math library) Emanuel Berg
2024-08-16 9:35 ` first-is (3 versions, Elisp hangup) (was: Re: we need *modularity* [last problem]) Emanuel Berg
2024-08-16 9:53 ` Emanuel Berg
2024-08-16 10:57 ` Eli Zaretskii
2024-08-18 16:38 ` as for Calc and the math library Richard Stallman
2024-08-18 17:27 ` Christopher Dimech
2024-08-19 12:05 ` Sv: " arthur miller
2024-08-24 2:59 ` Richard Stallman
2024-08-24 2:59 ` Richard Stallman
2024-08-15 9:31 ` Emacs ffi (was: Re: as for Calc and the math library) Andrea Corallo
2024-08-15 9:43 ` Eli Zaretskii
2024-08-15 20:32 ` Emacs ffi Andrea Corallo
[not found] ` <trinity-a24567af-9dc5-4e16-960c-c42d9759f282-1723755762558@3c-app-mailcom-bs05>
2024-08-16 20:07 ` Andrea Corallo
2024-08-16 21:21 ` Christopher Dimech
2024-08-17 6:06 ` Eli Zaretskii
2024-08-17 9:05 ` Christopher Dimech
2024-08-17 10:53 ` Eli Zaretskii
2024-08-17 13:21 ` Stefan Kangas
2024-08-17 14:30 ` Joel Reicher
2024-08-17 17:18 ` Christopher Dimech
2024-08-18 4:44 ` Emanuel Berg
2024-08-19 12:38 ` Sv: " arthur miller
2024-08-17 15:36 ` Christopher Dimech
2024-08-18 5:25 ` Emanuel Berg
2024-08-17 15:23 ` Andrea Corallo
2024-08-18 13:26 ` Björn Bidar
[not found] ` <87h6birmfy.fsf@>
2024-08-19 16:57 ` Richard Stallman
2024-08-19 17:22 ` Christopher Dimech
2024-08-17 2:21 ` Emanuel Berg
2024-08-14 14:35 ` as for Calc and the math library Gerd Möllmann
2024-08-14 14:40 ` Nicolas Martyanoff
2024-08-14 14:47 ` Gerd Möllmann
2024-08-14 14:49 ` Eli Zaretskii
2024-08-14 5:29 ` Madhu
2024-08-14 6:06 ` [ffi] " Madhu
-- strict thread matches above, loose matches on Subject: below --
2024-08-10 22:48 Emanuel Berg
2024-08-11 4:58 ` Eli Zaretskii
2024-08-11 16:45 ` Ihor Radchenko
2024-08-11 16:55 ` Christopher Dimech
2024-08-11 17:05 ` Emanuel Berg
2024-08-11 17:59 ` Eli Zaretskii
2024-08-11 18:17 ` Christopher Dimech
2024-08-11 18:32 ` Eli Zaretskii
2024-08-11 19:53 ` Christopher Dimech
2024-08-11 18:27 ` Ihor Radchenko
2024-08-11 18:38 ` Emanuel Berg
2024-08-11 18:52 ` Eli Zaretskii
2024-08-11 19:13 ` Ihor Radchenko
2024-08-12 2:24 ` Eli Zaretskii
2024-08-11 21:50 ` Christopher Dimech
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=861q2q8e18.fsf@gnu.org \
--to=eliz@gnu.org \
--cc=arthur.miller@live.com \
--cc=emacs-devel@gnu.org \
--cc=gerd.moellmann@gmail.com \
--cc=nicolas@n16f.net \
--cc=suhailsingh247@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).