Re: non-gnu elpa issue tracking

[Thibaut Verron]

Le sam. 12 déc. 2020 à 16:23, Tim Cross <theophilusx@gmail.com> a écrit :
>
>
>
> On Sat, 12 Dec 2020 at 21:08, Thibaut Verron <thibaut.verron@gmail.com> wrote:
>>
>> Le sam. 12 déc. 2020 à 07:37, Tim Cross <theophilusx@gmail.com> a écrit :
>> >
>>
>>
>> I also recall a discussion where some developers were worried that
>> assigning a copyright to the FSF was an official statement of
>> philosophical support, and that it was a statement they were not
>> willing to make. The official answer was that there is no such
>> statement in the copyright.
>
>
> As non-GNU ELPA is primarily about having a repository of packages which fit 
> with the FSF philosophy and which do not require copyright assignment, 
> concerns relating to copyright assignment are not relevant.

My point was that if assigning the copyright is not a statement of
philosophical support for the FSF, clearly, choosing the default
license (and possibly the only legal one) for an elisp file is also
not.

>>
>> > I think a mandatory requirement should simply be that any packages which 
>> > go into non-GNU ELPA are hosted on an approved platform. We could point to 
>> > a list of such hosting providers e.g. 
>> > https://www.gnu.org/software/repo-criteria-evaluation.html and say Grade C 
>> > or better only. .
>>
>> There is no such requirement for GNU ELPA at the moment.
>
> Perhaps there should be. However, GNU ELPA consists of code which has had 
> copyright assigned to the FSF, so I guess that is their call.

I might be mistaken, but as I understand it, the copyright assignment
does not give the FSF authority to move the repositories (including
issues, pull requests, etc), only to create a new one mirroring the
code.

It is always possible to remove those packages which are hosted on
Github, of course, but I don't know how many maintainers would be
willing to jump through hoops *again* to get their package readmitted.

>> > This will also have the added incentive of encouraging better hosting 
>> > options. It might even encourage GitLab for example, to enhance their 
>> > environment to meet Class B.
>>
>> Couldn't it just as well be an occasion to encourage Github to improve?
>>
> I strongly doubt it. Github has become a significant platform for Microsoft 
> and I see little interest from them in supporting the philosophy and goals of 
> the FSF.

Right, because they are evil and it's in their nature. But seriously,
I see interest in retaining their audience.

Gitlab is already gaining traction in several communities (e.g., from
first-hand experience, public research), and Microsoft knows that
Github is only popular for companies for as long as it is popular for
developers.

Asking Microsoft to completely give up control on Github is not
realistic of course. But small changes such as moving to a free
Captcha system, or giving repositories the option to allow anonymous
comments, why not?

>> > Many people have selected Github for hosting simply because it was the 
>> > best known solution. With a little encouragement, they would probably be 
>> > willing to move to at least GitLab, which offers many of the similar 
>> > convenience features of Github.  Being able to host your package in 
>> > non-GNU ELPA might be that encouragement.
>>
>> There is a lot of inertia involved in relocating a package with
>> hundreds of contributors.
>
>
> Hence adding a requirement to be hosted on a platform which furthers FSF 
> goals to help combat that inertia. People will have the choice - if they want 
> their package to go into non-GNU ELPA, move it to a more compliant hosting 
> environment or leave it where it is and don't worry about getting your 
> package into non-GNU ELPA.

In my opinion, they won't worry, just like they didn't worry about
getting their package into GNU ELPA before. Melpa works fine.

As I remember it, the discussion started with "why do people use Melpa
when there is GNU ELPA", and the more or less accepted answer was that
there is too much red tape for packages to be included in GNU ELPA.
Hence the NonGNU ELPA project, cutting down the requirements and not
even requiring initiative from the package maintainers. The only
requirement was that the package be free and not promote non-free
software.

It's okay to set stricter requirements and to ask maintainers to
comply if they want the privilege of having their package listed in
NonGNU ELPA. But then I won't be surprised if in 1 year the question
of "why do people use Melpa when there is GNU ELPA and NonGNU ELPA"
comes up.

> It also seems inconsistent to have so many packages, both GNU ELPA and 
> non-GNU ELPA packages hosted on a platform which is so far from being 
> acceptable from a FSF philosophical perspective. Makes it feel like the FSF 
> fails to eat their own dog food.

I agree. But I don't think that adding requirements is the answer.



>>
>>
>> I agree that some of the difficulties posed by copyright assignment do
>> not apply for relocation (e.g. that one contributor 7 years ago whom
>> nobody can contact), but there is an effort involved in both.
>
>
> Copyright issues are not relevant for non-GNU ELPA.
> --
> regards,
>
> Tim
>
> --
> Tim Cross
>