From: arthur miller <arthur.miller@live.com>
To: "rms@gnu.org" <rms@gnu.org>
Cc: "emacs-devel@gnu.org" <emacs-devel@gnu.org>
Subject: Sv: as for Calc and the math library
Date: Mon, 19 Aug 2024 12:05:40 +0000 [thread overview]
Message-ID: <DU2PR02MB101093C7871D4FBF5C153C77A968C2@DU2PR02MB10109.eurprd02.prod.outlook.com> (raw)
In-Reply-To: <E1sfivX-0007yr-0M@fencepost.gnu.org>
[-- Attachment #1: Type: text/plain, Size: 9075 bytes --]
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. ]]]
>
> > >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.
>
> You're right, and this is a possible problem, but it raises a real
> copyleft compliance issue only in a specific kind of occasion: when
> someone writes such an intermediary module that loads a nonfree
> library, _and distributes that intermediary module_ for such use.
>
> Just writing such an intermediary module and using it oneself does not
> raise a copyleft compliance issue, because GPLv3 says one can make any
> sort of modificatoin and use it privately -- even actually copying in
> nonfree code. Where the copyleft requirement comes into pkay is for
> making a modified version and distributing it to others.
Hi, and thank you very much for the clarification RMS. I saw you previous post
saying this also. I think it is useful to remind people that the GPL is about
the distribution and the rights to distribute the changed code not so much about
using the code (I think, I hope I am not sailing out of the clear water here).
> So it could be good to keep an eye on the modules that people are
> releasing, to make sure they do not load in other nonfree code.
> If they do, the FSF should tell their distributors to stop.
Yes, and this perhaps the only thing we can do, since technically it is very
easy to circumwent the license.
> Given this situation, a spcial label as a flag for "this library is
> free" might be useful, We just have to remember taht such a flag label
> is not proof of anything. Its presence is only a statement (which can
> be false) of intent that the module be entirely GPL3-compatible free
> code and that it link in only GPL3-compatible other modules.
Indeed. I don't know how realisict, technically and resource-wise it would be to
use Elpa as a place to distribute modules and to have each library in Elpa
"signed" or "approved" by someone FSF-trusted who could ensure the GPL license
is not violated. The problem I see is that after the initial review, libraries
are pulled and build automaticly from Git sources, so that would be a constant
process, but perhaps could be automated by a script which checks for presence of
certain system/library calls (dlopen & co) and warns an approved "reviewer" to
take a look at that library? I perhaps also misunderstand how Elpa works since I
am not so familiar with Elpa implementation. Problem with automation is that a
malicious author could, at least in theory, initially commit a perfect library,
and after some time introduce malicious or GPL-incompatible code. I am thinking
of the recent XZ-incident.
Since you have chimmed in, and in the light of your clarifications, may I ask
what do you think of the difference between doing the same thing from the Lisp?
Is there any conceptual difference between loading an external library from a
Lisp library as it is from a C library?
Since you have worked a lot with Lisp(s) in your past, and as I have seen from
the transcripts of the work on the CommonLisp standard, work in which you also
took part, you seem to always been concerned with how easy/difficult constructs
are to use and understand for users. In several contributions you tried to
simplify some constructs, at least as I understand (setf comes to mind for
example, but I don't remember the details at the moment, would have to look up
for the exact reference).
IMO it would be much easier and more convenient for EmacsLisp users and
programmers to use a Lisp interface to work with modules than C. Admittedly it
lowers the technical barrier for violating the GPL license, but that technical
barrier is a hindrance only for very innexperience programmers, who probably
wouldn't be able to use FFI from Lisp neither. As a layman when it comes to
licensing, I don't see the conceptual diffrence between a C library or a Lisp
library when it comes to licensing, and the very same "agreement" that should
uphold between a Lisp library writer, as there is between C library writer and
the GPL code they use.
If you can reflect on the conceptual difference I would be very thankful. I
promised to Eli I won't push for FFI, and I am not doing it either, but I am
interested to learn why it would be different to load a library via Lisp from
loading it from C, more than technical difference of doing it via Lisp is much
easier and convenient. If anyone, you have done lots of work in both Lisp and
C. I think it is very interesting to hear your opinion on the matter.
I hope Eli don't get too angry on me for asking you this, since I understand he
considers this off-topic. I understand it takes time and energy from you, when
we talk about this matters, and I appologize for that. This is also an
opportunity to hear what RMS opinion is and the reason why FFI is bad in
EmacsLisp, if he would be kind to explaing and clarify that one. I am sure I am
not the only one who will find this useful to hear. Perhaps I am just an idiot,
but I am not an enemy, and I don't mean harm as you seem to believe (since you
epressed the concern that I am just trolling to take your time). If you want to
send me the warning, or ban me from this list, so be it.
PS: I hope I didn't sent this twice. In a recent couple of weeks I have a problem with GNUs.
It sometimes works and sometimes not. Several of these mails I had to copy over to a
different client, happend this time, while some went out without problems from Emacs.
________________________________
Från: Richard Stallman <rms@gnu.org>
Skickat: den 18 augusti 2024 18:38
Till: arthur miller <arthur.miller@live.com>
Kopia: emacs-devel@gnu.org <emacs-devel@gnu.org>
Ämne: Re: as for Calc and the math library
[[[ 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. 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.
You're right, and this is a possible problem, but it raises a real
copyleft compliance issue only in a specific kind of occasion: when
someone writes such an intermediary module that loads a nonfree
library, _and distributes that intermediary module_ for such use.
Just writing such an intermediary module and using it oneself does not
raise a copyleft compliance issue, because GPLv3 says one can make any
sort of modificatoin and use it privately -- even actually copying in
nonfree code. Where the copyleft requirement comes into pkay is for
making a modified version and distributing it to others.
So it could be good to keep an eye on the modules that people are
releasing, to make sure they do not load in other nonfree code.
If they do, the FSF should tell their distributors to stop.
Given this situation, a spcial label as a flag for "this library is
free" might be useful, We just have to remember taht such a flag label
is not proof of anything. Its presence is only a statement (which can
be false) of intent that the module be entirely GPL3-compatible free
code and that it link in only GPL3-compatible other 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)
[-- Attachment #2: Type: text/html, Size: 21676 bytes --]
next prev parent reply other threads:[~2024-08-19 12:05 UTC|newest]
Thread overview: 73+ 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
2024-08-15 20:09 ` Sv: " 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 ` arthur miller [this message]
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
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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=DU2PR02MB101093C7871D4FBF5C153C77A968C2@DU2PR02MB10109.eurprd02.prod.outlook.com \
--to=arthur.miller@live.com \
--cc=emacs-devel@gnu.org \
--cc=rms@gnu.org \
/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 external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.