emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: PL support


From: Richard Stallman
Subject: Re: PL support
Date: Mon, 11 May 2020 23:17:19 -0400

[[[ 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, we do nothing of the kind.  Just because everybody and their dog
  > know what MELPA is and how to configure Emacs to use it, doesn't mean
  > _we_ told them.  Exactly like we don't "recommend" using MS-Windows,
  > although quite a few of Emacs users do, witness the discussions on
  > Reddit as one example.

We exist in a world in which lots of people willingly accept
practices that our goal is to eliminate.  That means we walk
a narrow ridge.  On one side, we could risk endorsing and
supporting exactly the wrongs we denounce.  On the other side,
we risk becoming less popular.

We want to avoid the latter, but we abolutely must avoid
the former.  Popularity is not success if it comes at the cost
of abandoning our goal.

Therefore we do not recommend MELPA.  We do not mention the existence
of about MELPA.  If people know about it anyway, that is not our doing
so we are not morally responsible.

Eli explained the details what this means.

Stefan wrote:

  > The way I see it, currently Emacs de-facto recommends to most of its
  > users to add MELPA to their `package-archives`.

To balance between the two cliff edges, we have to recognize both edges.
The expression "de facto recommends" denies one of them; it equates
staying on the ridge with falling off.  That would be self-defeating,
so we insist on the distinction and do not equate those.

  > Of course, those few not-quite-libre packages could pose problems for
  > that since they go against some of our values, so maybe we should not
  > add MELPA itself, but the "libre-MELPA" subset (which someone will have
  > to create and maintain).

That would not go against or morals.  It is not absolutely out of the
question.  But it would have a big drawback of a different kind: we
would effectively lose control over an aspect Emacs development.  We
want to keep some control over that, so we should not do this.

If the shorthand.el approach does enable us to fix our namespace problems,
that problem would be somewhat smaller; there would be a limit to
how bad it could get.

The other thing we try to achieve by recommending GNU ELPA and not
other ELPAs is to motivate package developers to do the two things
that enable us to put the packages into Emacs itself: sign
assignments, and rework them to fit our non-moral standards.
I think this is important.

-- 
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 via email to

[Prev in Thread] Current Thread [Next in Thread]