Re: non-gnu elpa issue tracking

[Christopher Dimech <dimech@gmx.com>]

> Sent: Saturday, December 12, 2020 at 9:46 PM
> From: "Stephen Leake" <stephen_leake@stephe-leake.org>
> To: "Tim Cross" <theophilusx@gmail.com>
> Cc: "Jean Louis" <bugs@gnu.support>, thibaut.verron@gmail.com, "Stefan Kangas" <stefankangas@gmail.com>, "Boruch Baum" <boruch_baum@gmx.com>, "Emacs developers" <emacs-devel@gnu.org>, "Stefan Monnier" <monnier@iro.umontreal.ca>, "Richard Stallman" <rms@gnu.org>
> Subject: Re: non-gnu elpa issue tracking
>
> Tim Cross <theophilusx@gmail.com> writes:
>
> > On Sun, 13 Dec 2020 at 00:50, Stefan Monnier <monnier@iro.umontreal.ca>
> > wrote:
> >
> >> > The non-GNU ELPA is supposed to be a repository for packages which are
> >> GPL
> >> > compliant and it is a reasonable expectation that those who make their
> >> > packages GPL compliant do so because they support the philosophical goals
> >> > of the FSF.
> >>
> >> The overwhelming majority of ELisp packages out there are hosted on
> >> Github (that also applies to many GNU ELPA packages, many of them are
> >> developed by long time contributors to Emacs), so I think the evidence
> >> shows the above expectation doesn't hold at all.
> >>
> > Maybe. However, it could also be a combination of the fact github was the
> > first free git hosting environment and is the better known one. Just
> > because it is this way now doesn't mean it has to be. If the GNU/FSF
> > doesn't take a clear position on this and do something to discourage the
> > use of hosting environments that force the use of proprietary software,
> > this will not change and eventually all we will have are the proprietary
> > solutions. It may not have been the right decision to allow code which has
> > assigned copyright to the FSF to remain on Github. However, as non-GNU ELPA
> > is just getting started, now would be a good time to try and change
> > things.
>
> +1.
>
> I think we should encourage people to move away from Github, for both
> GNU and non-GNU ELPA.
>
> Given that many ELPA packages are now on Github, we could have a
> transition policy, with enforceable deadlines (ie, remove package from
> *GNU ELPA if still on gitub after deadline). However, I doubt that the
> Emacs project is capable of such a thing, or that we want to be.
>
> So we are left with naming and shaming; in list-packages, show the
> upstream repository along with the license and other info on a package,
> and show unacceptable ones in red. That could still be a lot of effort
> to categorize obscure hosts.

I do not see how putting a copy on GitHub is an offence.  We can discourage it,
But removing packages from GNU ELPA if still on Github after deadline, is
not the way forward.  Removing free software from ELPA is a regressive move
that will not benefit Gnu in any way.

> Disclaimer; my packages are hosted on Savannah, so any resolution of this
> will have no direct impact on me.
>
> --
> -- Stephe
>
>