RE: enable MELPA & Marmalade by defaul [was: mykie.el]

[Drew Adams <drew.adams@oracle.com>]

Hi Eric,

> >> > Why shouldn't GNU Emacs enable all three by default?
> >> > That would help GNU Emacs users more, I think.
> >>
> >> One easy answer is that MELPA and Marmalade are non under the
> >> control of the Emacs prooject.
> >
> > So?  GNU Emacs is not responsible for whatever it might be that
> > those repos have or do.  And I think we (should) know by now
> > that most, if not all, of what they do can be helpful for Emacs
> > users.
> 
> I think this falls into the category of "should a GNU project
> recommend repositories that contain non-free software?"

Putting them in the available-by-default list does *not*
recommend them, IMO.  And it is certainly possible for GNU
Emacs to post a big banner saying that the ONLY repository
it recommends is its own ELPA repository, genuine GNU ELPA.
Nothing wrong with that.  Would that satisfy your
recommendation worry?

And anyway, nothing says that those repositories involve much
non-free software, or even any at all.

Without looking, I'd bet that the *overwhelming mass* of packages
in those two repositories are free software (GPL'd).  Why make
users jump through extra hoops to access all that free software,
even if there might also be a non-free package there somewhere?

Do you think that a downloading user cannot tell whether some
software is free or not?  If so, is this about trying to hide
that non-free software from their unsuspecting hands, so they
cannot make the awful mistake of not recognizing it?

If so, that kind of protection-by-ignorance is doomed to be
ineffective and even counterproductive in the long run, IMHO.

> RMS and his defense of the FSF position (and composure in
> the face of very shabby treatment) are remarkable.

Agreed 100%.  And so?  Has RMS said that listing those two
repositories would hurt free software?  Maybe a lawyer from
the FSF will chime in.  (As if we didn't get enough
software-development-by-legal-department these days..., but
I digress.)

> If Emacs (or any GNU/FSF program) actively prevented the
> installation of software, or surfing to a site of the users'
> choice, that would be censorship.

I did not suggest that.  I suggested listing those repos
by default.  That neither censors access to them nor
particularly recommends them (IMO).

How about my Samsung - Netflix analogy?  Do you think you'd
stand a chance if you sued Samsung because one of Netflix's
films offended you?  Is Samsung liable for bad Netflix films
because it makes Netflix available by default on your new TV?

Your public library (that nasty socialist institution!) no
doubt has some books that some people might find objectionable.
The library does make a selection - it decides what to make
available.  But that does not mean that the library censors
those books that are not in its catalog.  And it does not mean
that the library necessarily recommends each of its books for
each of its readers.

Some users perhaps should not read some books or install some
software packages, at least not until they feel they are ready
and want to do so.  That does not mean that books or software
that might be helpful to other users (even perhaps most users)
should not be made easily available to them.

It is my guess that the vast majority of packages in those two
repositories (a) are useful to at least _some_ Emacs users,
(b) are probably not poisonous to _any_ Emacs users, and (c)
are likely not at all problematic for _most_ Emacs users.
Do you have a different guess in this regard?  (Please note
the qualifiers, in particular "vast majority".)

If that is the case (folks here can make that judgment/guess),
then is it more helpful to users to add those two repositories
to the default list?  I think so. You are welcome to disagree.

> It is another matter entirely to _recommend_ the software
> sites, because the FSF believes that this constitutes some
> form of complicity in leading someone astray. (Whether the
> end-user believes it is immaterial.)

Sorry, I really do not see it that way.  But then, I am not
a lawyer.  I'm thinking about what could be most helpful for
most users (in my judgment).

I do not see simply listing MELPA by default as constituting
a blanket endorsement of everything on MELPA.  I cannot
imagine that any user would see it that way.  (A lawyer who
wants to make his job easier might see it that way, or at
least say that he does.)

> > Think users, not lawyers.  This is not GNanny, or at
> > least it did not used to be.
> 
> It is trivial for a user to enable these repositories.

Maybe so, but I have seen questions here and there about
doing so.  List them and it becomes even more trivial.
And no doubt it is just as trivial to remove one from the
list, or to simply ignore it, no?

And to enable them, they need to know they exist.  Listing
them by default obviates a separate discovery step: here
they are.

Just what are you trying to protect users or GNU Emacs
from?  It's a serious question.  I'd like to get a
specific answer.

So far, we've heard about the bogeyman of "(all?)" MELPA
packages destroying a user's environment or whatever
(nothing about free software in that scarefest).  That's
one extremely vague anecdote from Oscar about one user
having had one bad experience.  Sheesh.

And now we've gotten a vague catastrophe scenario from you
about free software being somehow polluted and dragged down
to depravity and degradation by inadvertent downloading of
non-free software.

But seriously, what is the *real track record* for the 1487
packages on MELPA and the *hundreds of thousands* of package
downloads from MELPA so far?  Any knowledge of mass suffering?
Any statistics about non-free software corrupting
free-software environments or users?

The experiment has been running for a while now.  Surely
we should know by now if there is a big problem here that
really needs preventing.  No?  What's the story - real
danger or not?

> What is not trivial is endeavoring to maintain a libre software
> installation, but having non-free repositories enabled.  It is truly
> shocking that proprietary "feature-enhancing" extensions can get
> installed onto a system by package managers, though the selected
> software package (e.g. Chromium) was in fact libre.

Any evidence that that has anything to do with the question
at hand?
 
> From another perspective, it makes it difficult to develop software
> systems for commercial purposes, because can't be sure that my
> company can use for any purpose or redistribute the codes.

I think you are really exaggerating there (but I am not a lawyer).

That sounds very much like the kind of thing one sometimes hears
in commercial companies about GNU (!) and why GNU software should
be avoided like the plague by companies because it supposedly
sucks all of the company's own software into a free-software
tainted purgatory.  Dueling bogeymen.

> In principle, a repo author may rise like a submarine, when he
> discovers that he could strike it rich because of (unintended)
> license violations.  IANAL, but I believe that unless otherwise
> stated, all rights are reserved.

Sounds like we need to hear from a law expert about this.
All of that sounds wildly exaggerated to me.

Just because a repository might have some packages (and is that
even sure?) that are not free software, even if it also has
hundreds of useful free-software packages (which I think is the
case), is it the end of the world for GNU Emacs to list that
repository?

In that scenario, I would say that the benefit (to users, and
to Emacs itself) would *FAR* outweigh whatever cost you imagine
to free software.

But perhaps (no doubt) I am not grasping the seriousness of the
threat to free software posed by listing these two repositories.
So far, I've seen nothing specific - only bogeymen and vague
Chicken Little alarmism.  Where's the beef?

I do appreciate the concern.  I suspect that it is misplaced.
But I, like you, am not a lawyer.  I realize that I am likely
seeing a small part of a bigger picture.  Lawyer input welcome.