From: Richard Stallman <rms@gnu.org>
To: Tim Cross <theophilusx@gmail.com>
Cc: emacs-devel@gnu.org, thibaut.verron@gmail.com,
stefankangas@gmail.com, bugs@gnu.support, boruch_baum@gmx.com
Subject: Re: non-gnu elpa issue tracking
Date: Sat, 12 Dec 2020 23:58:47 -0500 [thread overview]
Message-ID: <E1koJT5-0006mH-UE@fencepost.gnu.org> (raw)
In-Reply-To: <CAC=50j_jAGd0t-trAECag54y6VpJz0cjk0Y5AnV81aPckLJxTg@mail.gmail.com> (message from Tim Cross on Sat, 12 Dec 2020 17:37:10 +1100)
[[[ 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. ]]]
> The non-GNU ELPA is supposed to be a repository for packages which are GPL
> compliant and it is a reasonable expectation that those who make their
> packages GPL compliant do so because they support the philosophical goals
> of the FSF.
I wish this were true, but it is not. Our influence is limited. (It
would get stronger if more people showed support for our goals in
a visible way.)
There are some things we must refuse to do, because doing them would
put us in a moral contradiction. "Please do X", where doing X requires
running a nonfree program, is one thing we must not say. And we must
not agree to do X ourselves.
However, to go beyond that can be strategically unwise. To reject
packages simply because the developers release them on GitHub would be
self-defeating. To try to pressure those users to move off GitHub
when we do not _need_ that would create avoidable friction.
Of course, we won't lead users to download those packages from GitHub.
We will lead users to download them from NonGNU ELPA.
By the way, I think the term "GPL-compliant" has a misunderstanding in
it. Strictly speaking, the time when you must comply with the GPL (or
whichever license L) is when you reuse material released under that
license. Thus, a software distribution is GPL-compliant if the
GPL-covered materials in it are used in accord with the GPL. If it is
NOT GPL-compliant, that means it is a GPL violation.
That is the only valid use of the term "GPL-compliant", and I am
pretty sure it is not what you mean. You are talking about something
done by the developers themselves, so it must be something else.
Perhaps you mean that the package carries a license compatible with
our license (GPL version 3-or-later). Is that right? That is indeed
something we must insist on. But it does not mean we must insist that
the developers follow all the best practices we recommend, or implore
people to follow.
> As I understand it, non-GNU ELPA is not supposed to be
> a repository for all other packages where the author doe snot want to
> assign copyright to the FSF. It is supposed to be for all other GPL
> compliant packages where the author does not want to assign copyright to
> the FSF.
Actually it is not intended as a repository at all. It is a place for
distributing packages, not for developing them. It is more similar
to MELPA, but curated.
NonGNU ELPA is our plan for distributing to users any and all packages
which we would like to distribute, and for which there is no big
obstacle to our doing so.
We would like to minimize what we need to ask the developers of those
packages to do for us and with us -- to ask only for what we _need_.
There are some things we need. For instance, for moral reasons.
In principle, we CAN include (that is, redistribute) a package even if
it has no developers and is unmaintained. We can say, "Here it is,
use it if you like it, we can't fix it." But we can't tell users to
run a nonfree program to report bugs.
--
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)
next prev parent reply other threads:[~2020-12-13 4:58 UTC|newest]
Thread overview: 83+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-12-09 12:55 non-gnu elpa issue tracking Boruch Baum
2020-12-09 16:58 ` Stefan Kangas
2020-12-09 19:18 ` Jean Louis
2020-12-09 21:48 ` Stefan Kangas
2020-12-09 23:40 ` Jean Louis
2020-12-09 23:58 ` Jean Louis
2020-12-11 6:09 ` Richard Stallman
2020-12-11 6:05 ` Richard Stallman
2020-12-10 4:32 ` Richard Stallman
2020-12-10 6:28 ` Jean Louis
2020-12-09 19:23 ` Jean Louis
2020-12-09 23:22 ` Thibaut Verron
2020-12-10 0:09 ` Jean Louis
2020-12-10 9:14 ` Thibaut Verron
2020-12-10 11:23 ` Stefan Kangas
2020-12-10 14:19 ` Thibaut Verron
2020-12-10 16:37 ` Jean Louis
2020-12-11 6:10 ` Richard Stallman
2020-12-10 11:49 ` Jean Louis
2020-12-10 14:05 ` Stefan Kangas
2020-12-10 15:48 ` Stefan Monnier
2020-12-10 16:05 ` Jean Louis
2020-12-10 17:35 ` Stefan Monnier
2020-12-11 6:09 ` Richard Stallman
2020-12-11 6:04 ` Richard Stallman
2020-12-11 11:10 ` Thibaut Verron
2020-12-12 5:34 ` Richard Stallman
2020-12-12 6:37 ` Tim Cross
2020-12-12 10:08 ` Thibaut Verron
2020-12-12 15:23 ` Tim Cross
2020-12-12 17:07 ` Thibaut Verron
2020-12-13 4:56 ` Richard Stallman
2020-12-13 5:20 ` Tim Cross
2020-12-13 9:54 ` Andrea Corallo via Emacs development discussions.
2020-12-13 22:59 ` Tim Cross
2020-12-14 0:32 ` Stefan Monnier
2020-12-14 0:54 ` Tim Cross
2020-12-14 4:36 ` Stefan Monnier
2020-12-14 5:45 ` Tim Cross
2020-12-15 5:44 ` Richard Stallman
2020-12-14 10:03 ` Alfred M. Szmidt
2020-12-14 14:57 ` Stefan Monnier
2020-12-14 15:01 ` Alfred M. Szmidt
2020-12-14 15:12 ` Stefan Monnier
2020-12-14 15:52 ` Eli Zaretskii
2020-12-14 0:16 ` Stephen Leake
2020-12-13 4:56 ` Richard Stallman
2020-12-13 8:56 ` Vasilij Schneidermann
2020-12-14 5:50 ` Richard Stallman
2020-12-14 6:45 ` Jean Louis
2020-12-12 13:48 ` Michael Albinus
2020-12-12 13:50 ` Stefan Monnier
2020-12-12 15:37 ` Tim Cross
2020-12-12 19:54 ` Jean Louis
2020-12-12 20:46 ` Stephen Leake
2020-12-12 21:24 ` Alfred M. Szmidt
2020-12-12 21:48 ` Christopher Dimech
2020-12-13 0:39 ` Tim Cross
2020-12-13 1:28 ` Christopher Dimech
2020-12-13 5:03 ` Richard Stallman
2020-12-13 4:58 ` Richard Stallman
2020-12-12 21:06 ` Dmitry Gutov
2020-12-13 4:58 ` Richard Stallman [this message]
2020-12-13 5:27 ` Christopher Dimech
2020-12-12 19:33 ` Jean Louis
2020-12-12 21:24 ` Alfred M. Szmidt
2020-12-13 4:59 ` Richard Stallman
2020-12-13 5:03 ` Richard Stallman
2020-12-14 17:38 ` Jean Louis
2020-12-14 18:49 ` Vasilij Schneidermann
2020-12-14 22:13 ` Jean Louis
2020-12-14 19:10 ` Boruch Baum
2020-12-14 22:17 ` Jean Louis
2020-12-16 5:32 ` Richard Stallman
2021-01-02 5:25 ` Richard Stallman
2020-12-10 4:35 ` Richard Stallman
2020-12-10 5:03 ` Boruch Baum
2020-12-10 5:55 ` Eli Zaretskii
2020-12-10 6:39 ` "Open records", "good government principles", "corporate culture" Boruch Baum
2020-12-10 7:27 ` Jean Louis
2020-12-10 14:08 ` Eli Zaretskii
2020-12-11 6:16 ` Richard Stallman
2020-12-10 6:54 ` non-gnu elpa issue tracking Jean Louis
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=E1koJT5-0006mH-UE@fencepost.gnu.org \
--to=rms@gnu.org \
--cc=boruch_baum@gmx.com \
--cc=bugs@gnu.support \
--cc=emacs-devel@gnu.org \
--cc=stefankangas@gmail.com \
--cc=theophilusx@gmail.com \
--cc=thibaut.verron@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).