Re: non-gnu elpa issue tracking

[Tim Cross <theophilusx@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 5916 bytes --]

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

[-- Attachment #2: Type: text/html, Size: 7689 bytes --]