From: Christopher Dimech <dimech@gmx.com>
To: rms@gnu.org
Cc: thibaut.verron@gmail.com, bugs@gnu.support,
Tim Cross <theophilusx@gmail.com>,
boruch_baum@gmx.com, emacs-devel@gnu.org, stefankangas@gmail.com
Subject: Re: non-gnu elpa issue tracking
Date: Sun, 13 Dec 2020 06:27:30 +0100 [thread overview]
Message-ID: <trinity-4d86f147-b171-43b9-812e-f098d7363386-1607837250830@3c-app-mailcom-bs11> (raw)
In-Reply-To: <E1koJT5-0006mH-UE@fencepost.gnu.org>
> Sent: Sunday, December 13, 2020 at 5:58 AM
> 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
>
> [[[ 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.
Quite the right approach.
> 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.
In some way, the license needs to be compatible, or has the ability to
re-license for compatibility with Emacs.
> > 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.
That's right.
> 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.
Agreed
> --
> 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 5:27 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
2020-12-13 5:27 ` Christopher Dimech [this message]
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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=trinity-4d86f147-b171-43b9-812e-f098d7363386-1607837250830@3c-app-mailcom-bs11 \
--to=dimech@gmx.com \
--cc=boruch_baum@gmx.com \
--cc=bugs@gnu.support \
--cc=emacs-devel@gnu.org \
--cc=rms@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 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.