Re: PL support

[Stefan Monnier]

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

If I were a maintainer or contributor of MELPA, I'd be offended by what
you wrote.  While MELPA does contains a few Free Software packages which
only work when coupled with proprietary software, the *vast* majority of
the packages are nothing but Free Software.

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

Our unwillingness to make Free Software packages like Magit or Tuareg
easily installable into Emacs with no extra configuration forces many
of our users to add MELPA to their `package-archives`.

So, I stand by my claim that we de facto recommend to most of our
users to add MELPA to their `package-archives`, and if you think we
don't, I think you're just deluding yourself.

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

I think your judgment is quite faulty here, for the simple reason that
you don't understand the extent of the amount of development that's
taking place outside of emacs-devel and over which we hence already have
no control.


        Stefan