bug#59609: 29.0.50; [PATCH] Better advertise (Non-)GNU ELPA in emacs manual

[Eli Zaretskii <eliz@gnu.org>]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: Stefan Kangas <stefankangas@gmail.com>,  59609@debbugs.gnu.org
> Date: Fri, 08 Sep 2023 12:43:15 -0400
> 
> > It's a good starting point, but the copyright assignment issue is not
> > the only issue (not even the main one, from my POV).  The main issue
> > with NonGNU ELPA, IMO, is that packages there don't necessarily adhere
> > to the Emacs coding conventions, are not supervised by the Emacs
> > maintainers, and do not have to coordinate their development decisions
> > with the Emacs team.  So their integration into Emacs could be less
> > seamless than that of packages from GNU ELPA.
> 
> FWIW, GNU ELPA packages don't necessarily "adhere to the Emacs coding
> conventions" either and neither are they all "supervised by the Emacs
> maintainers" or "have to coordinate their development decisions with the
> Emacs team".  Some do, but not all of them by a long shot.

Only because we decide not to do that, or are lazy, or whatever.
Basically, it's our decision for GNU ELPA, and not so for NonGNU ELPA.

> In practice the real deciding factor *is* the copyright assignment
> (which often ends up selecting for a kind of "philosophical agreement"
> about the primacy of ethical goals over technical ones).

I think this is just the tip of a very large iceberg, and the FAQ
should say that explicitly.  Saying that just the CA is the difference
is both very inaccurate and misrepresents the actual situation: NonGNU
ELPA is a collection of packages that someone else decided could be
useful, but we basically have nothing to do with them except hosting
them.