Re: non-gnu elpa issue tracking

[Jean Louis]

* Thibaut Verron <thibaut.verron@gmail.com> [2020-12-10 12:15]:
> Le jeu. 10 déc. 2020 à 09:32, Jean Louis <bugs@gnu.support> a écrit :
> >
> > * Thibaut Verron <thibaut.verron@gmail.com> [2020-12-10 02:23]:
> > > >
> > > > My opinion is that non-GNU ELPA and GNU ELPA both should never point
> > > > to any website that has any proprietary Javascript or promotes
> > > > proprietary software, specifically hyperlinks to Github better be
> > > > removed completely.
> > > >
> > >
> > > Without backlinks to the original repositories, how will people know where
> > > to report bugs with packages installed from non-GNU ELPA?
> >
> > My opinion is that nothing offered within Emacs, be it ELPA packages
> > or now non-GNU ELPA packages should guide users to any non-free
> > software, especially not websites with non-free Javascript like
> > Github.
> 
> Would gitlab be acceptable, at the very least?

Not my decision. Developers decide on that.

Maybe people wish to see this reference:
https://www.gnu.org/software/repo-criteria-evaluation.html

There are many similar.

Codeberg.org (Germany)
https://codeberg.org

Sourcehut.org
https://sourcehut.org

Trisquel GNU/Linux-libre Git Repositories
https://devel.trisquel.info/groups/trisquel

Pagure
https://pagure.io/pagure

Fosshost
https://fosshost.org/

GitGud - Fast and Free Git Hosting
https://gitgud.io/users/sign_in

> > Author name should be there, email address and there can be URL as
> > per: (info "(elisp) Simple Packages")
> >
> > I would change that URL to point to non-GNU ELPA repository as it
> > becomes not only plain distributor but slight fork of the
> > package. There is nothing wrong with it. People can still use author's
> > name and email to report directly.
> 
> I personally would be annoyed if users started reporting bugs directly
> to my e-mail. I cannot imagine how it would be for high-traffic
> packages.

Packages live their URL and author's name. I do not think that
licenses forbid changing the URL. Normally one has to tell who are
authors and provide license. From that viewpoint whatever authors
write in the package commentary or README file will be used by users.

non-GNU ELPA is more similar to a fork. As the control will be
maintained which packages are distributed to users and what is changed
there or modified. In that sense it can be that for some features we
start reporting to non-GNU ELPA, and not to upstream. We discussed
here that it is desirable to make relations with upstream authors. But
what if they do not wish? Then packages, as they are free software,
may be distributed and modified in non-GNU ELPA without notification
to author.

> And what about packages with extensive guidelines for reporting bugs?
> Should they now include those guidelines in the package description?
> And would you amend those guidelines to remove references to github,
> too?

I don't think so and I am not authorized to make statements on that. I
think that general questions do not lead to useful solution. There is
no need to make hypothetical conclusions as there is no specific
package to talk about.

> I thought that the point of non-GNU ELPA was to bridge the gap between
> the emacs developers and the "community developers". But this kind of
> minor ideological changes, in my opinion, is more likely to antagonize
> developers.

I see it quite contrary. People will get interested and will apply to
non-GNU ELPA with their proposals. There are limits mostly related to
free software principles, there are packaging guidelines, there is
certai limit how many packages can be handled by developers in what
period of times. By opening non-GNU ELPA GNU project is doing exactly
what you said, providing a bridge that any Emacs Lisp developers,
may get their packages easier discovered by default.

We shall not forget that option to include the package to GNU ELPA
always existed and exists today. Everybody is welcome. Naturally those
who have proprietary packages would need to adopt their license for
that to take place.

Sorry, I cannot see minor ideological changes, in fact I see no
ideological change at all since decades.

If we wish to compare it to MELPA, we today discovered that MELPA
practically distributes proprietary software. Then a person discovered
that the license does exist somewhere else on Github. If I would have
package there and license in the same repository that would make me
feel unjust that somebody like MELPA is fetching my package and not
distributing license with it. In that sense MELPA is changin the
author's package without author's knowledge. That is all by mistake
and some neglect, not by bad intention.

While changing author's package MELPA is not antagonizing anybody, so
will non-GNU ELPA not antagonize anybody. Quite contrary, people wish
to integrate with each other and help each other.

As I said, hypothethical talk is not useful. Bring a package and ask
if such can be included. Let us see, that we do not create problems
out of nothing. I am sure that Emacs developers already have lists of
packages in their mind and will come to it soon.

> Am I correct to understand that if some developers decide that they do
> not want their package included in non-GNU ELPA, the only way that
> they can enforce this decision is to use a less permissive license for
> future releases?
> 
> I don't think that we want to encourage such a choice.

Maybe you review again what is free software. As I already pointed, if
you have account on Github, within seconds you can already fork other
people's software, and you do not need to ask people about that. They
have already given explicit permission that you may copy software,
modify it, distribute it.

I do not see practical reason why would a developer object that free
softwar package is distributed, copied, modified from some other place
than original repository? If they do object, they can tell their
opinion, but nevertheless the rights obtained by free software license
cannot be just taken back as author wish and want.

Thus the hypothetical case you explained above I cannot see happening.

Quite contrary I feel that when Emacs packages are distributed that
authors have certain pleasure when other people use the package how
they wish and want.

> > Remember that this does not prevent other users of any other website
> > such as MELPA to use their hyperlinks how they like. T
> >
> > This opinion is for specifically for Emacs that should never point to
> > non-free websites and relates to ELPA as well.
> >
> > So I do not see any real problem there. Those using MELPA will do what
> > they wish.
> 
> I thought the goal of non-GNU ELPA was to make MELPA necessary only
> for non-free packages, and thus useless of the vast majority of
> users.

That would be negative goal that goes into wrong direction. If MELPA
is useful or not useful it does not matter.

It is different project with a different set of ethical
principles. GNU is different project with different sent of ethical
principles. Goal for GNU is to provide free operating system and for
Emacs packages to be useful free software accessible by default
without user having to stumble upon or being guided into non-free or
proprietary software.

Goal is not to make other repository useless. Various groups and
communities do what they want. GNU project is always proposing to use
free software, to distribute licenses correctly, it teaches users
about free software. If some separate project like MELPA provided
non-free software then such will get less and less recommended by GNU
project or never at all. As simple as that.

It is analogous to Archlinux that has open policy to accept any
software including proprietary as long as authors agree that it can be
distributed from Archlinux. GNU project cannot possibly recommend
Archlinux to users. That does not mean that GNU project is working
against Archlinux to make it useless. Nothing changed fundamentally in
GNU project, what changed is in those other communities.

> If "non-free" now includes all those packages whose developers don't
> want to deal with issues outside of github, it can become a lot more
> extensive.

That is not definition of non-free. Remember that my opinion is
personal, not authorized for GNU project to speak of final decisions.

If I understand it well you mean that some issues to maintain packages
will be sent by Emacs users and such issues may not arrive to
developers of upstream package? People discussed it already here that
non-GNU ELPA should establish relations with authors so that authores
can contribute directly to non-GNU ELPA.

Compare that to Github fork:

1. User clicks to fork the package. Author is not asked
   anything. Package is just forked. They may not even speak to author
   ever.

2. Or telling author kindly that non-GNU ELPA is now interested to
   distribute the package and if author wish to maintain it directly.

Those questions rather apply to Github, not to GNU.

Please remember that license gives rights to copy, modify, distribute
packages as users wish and want.

When doing so, I could change all original URLs and point back to my
URL as long as license is respected. I could now say: I do not wish to
take any reports or bugs, issues, as they are not welcome. That is
what many people do when they finish with the package. They will say
take it and do what you wish with it, it is free software, but I have
not time for it.

> > And those using non-GNU ELPA would report there where
> > developers decide, but not on Github, provided this type of proposal
> > is accepted.
> 
> What is "there" in this context? And who are "developers"?

Remember, me not authorized for Emacs developers.

I am expressing personal opinion. Emacs developers will decide how
they will publish software they package in non-GNU ELPA. They have yet
to say how to report bugs on such packages.

I would not like if GNU project would start pointing to people: go
back to Github and report bugs there for reason that users are driven
or guided to non-free software and unethical software repositories.

When making those comparisons and analyzes I suggest that you first
compare it to what is already at hand and present in the world.

Example is Melpa, you are free to pull sources for Melpa and open up
your own server providing your own ELPA. It is trivial to do so as
they have given website, and scripts available for everybody. Maybe
main problem is that people do not know how to setup their own
servers. When doing so, pulling software, everybody is free to modify
what is free software and offer to others. Melpa is doing that on each
software package by modifying their version numbers and other meta
data. Isn't modification of a version number against author's
decision? I think it is. But it is free software and Melpa is free to
do what they wish. They can say that version number is 2 when it is
1. Free software.

GNU/Linux distributions such as Debian modify the software with
patches. They desire but do not need to ask original authors. What is
more important is maintainer of a package who does the job and
prepares package to be compatible with other packages. Imagine if
Debian would be waiting for authors to start acting upon something
they maybe long forgotten or do not maintain.

Companies like Redhat have been modifying Linux kernel. Many companies
modified Linux kernel without necessarily informing developers. Free
software. But as long as kernel is distributed developers could get
those modifications back. 

Compare those thoughts of today to that what is already present in the
world to see that there is nothing different in non-GNU ELPA in the
context of software modification and distribution.

Jean