unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
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)
>
>
>
>



  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

  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=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 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).