Re: non-gnu elpa issue tracking

[Jean Louis]

* Boruch Baum <boruch_baum@gmx.com> [2020-12-09 15:57]:
> 1) License disclosure: The summaries indicate that RMS is open to having
>    the repository host packages bearing *any* free license, but there
>    may be users who are pickier, so a package's license should be
>    disclosed prominently on the listing page and the package detail
>    page;

For me it was natural that free software license should be GPL
compatible license, so I was consulting this page when reviewing a
pattern of licenses:
https://www.gnu.org/licenses/license-list.html#GPLCompatibleLicenses

Example is public domain but not CC0 where such package is not
compatible with the GPL as it is not compatible with world
jurisdictions. Many would not recognize "public domain" and that
renders software proprietary.

I think that new column or license in the description of the package
would be beneficial. The stance alone that licensing is important and
that GPL compatible licenses are acceptable is also good for people to
get awareness.

> 2) The acceptance or candidacy process for each package should be
>    documented in some discrete method. Melpa does this using github's
>    pull request feature, which documents the entire conversation related
>    to the process of accepting a package.

It should be clear now that some packages do not even bear any license inside.

kiwix-20200714.1357.tar - has no license inside. Maybe it has in the
original repository, but the license must be given explicitly. If not
given explicitly with software it is proprietary. If it was a mistake
by Melpa's workflow then Emacs developers could try to look into the
original repository and fetch software from there. This would be
anyway better.

Those are 2 examples showing that Melpa does not do the job well and
there are hundreds of other examples. 

That shows  that their process of documenting acceptance of the
packages is flowed, and process of distributing packages is flowed.
Melpa distributes proprietary packages. There is no need to compare to
it.

As the major difference between GNU ELPA and Melpa is ethics, one need
not compare ethical repository to the one lacking ethical principles.

Let us say if I wish to make private repository of Emacs packages I
would not be discussing with anybody, I would just make it. 

> 3) After a package is initially accepted to the repository, the
>    summaries of Richard Stallman's presentation indicate that subsequent
>    commits or releases may be rejected or modified. That record should
>    also be documented. Debian does this using its own package tracking
>    software.

If there is a mailing list where people apply with patches it would
get automatically recorded. Just as now for Emacs and GNU ELPA
packages.