emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: non-gnu elpa issue tracking


From: Tim Cross
Subject: Re: non-gnu elpa issue tracking
Date: Sun, 13 Dec 2020 11:39:36 +1100

Just to clarify a bit.

I am not suggesting we remove packages which fail to migrate from github/sourceforge to a more complaint hosting environment. A decision could be that we ask existing maintainers to move and require that all new packages from a specific date are only on a supported hosting environment. I raised this suggestion now specifically with respect to non-GNU ELPA because that is a relatively new repository and as such, it could be a good place to start with for establishing a repository which is more in line with FSF philosophy and goals. In some sense, it could be a testbed to refine a more general repository approach that might be applied to GNU ELPA at some point in the future. 

I would never agree to a 'name and shame' approach. That is seldom an appropriate course of action and can only be justified when there are very serious direct consequences. What we want here is increased incentive, a carrot, not a stick. 

With respect to Github and Microsoft, I have little confidence in the proposition we could put pressure on Github to adopt practices that are in-line with FSF philosophy. Microsoft is a public company run by a board of directors who have an obligation to maximise the share prices and dividends for the shareholders. Ultimately, decisions are based on maintaining and increasing profit. The ability to make decisions to further such profit generation is closely tied to control. This makes any decision which gives up control less likely to be welcomed. I have little confidence Microsoft would be willing to give up the level of control necessary for it to become accepted under FSF guidelines as an ethical hosting provider. Some minor cosmetic changes might be possible, but little more. We would probably have better success moving Gitlab from Class C to Class B with respect to providing an FSF compliant hosting platform.

My main point here is that many of the problems associated with maintenance of packages, such as issue tracking, are being significantly complicated because the code is being maintained on a platform which does not meet GNU/FSF guidelines, philosophy and goals. If a key goal of the FSF is to promote an ethical position with respect to software, it has to prioritise that ethical position over convenience. Convenience is probably the number one threat to software freedom.  Rather than focus on the inconvenience of requiring maintainers to use a more appropriate hosting platform, consider the potential benefits with respect to issue tracking and maintenance that would be possible without the limitations and confusion caused by the current situation.  Furthermore, consider the benefits to the core message of having an ecosystem which is actually based on more ethically compliant systems. 



On Sun, 13 Dec 2020 at 08:48, Christopher Dimech <dimech@gmx.com> wrote:
> 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
>
>


--
regards,

Tim

--
Tim Cross


reply via email to

[Prev in Thread] Current Thread [Next in Thread]