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 02:23:43 +1100



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. 

> Therefore, I don't think it is too much to ask that they also have those packages hosted on a platform which also supports these same philosophical goals. As I understand it, non-GNU ELPA is not supposed to be a repository for all other packages where the author doe snot want to assign copyright to the FSF. It is supposed to be for all other GPL compliant packages where the author does not want to assign copyright to the FSF.

Or can't. In a lot of cases it turns out that contacting all
contributors to obtain copyright assignment is a difficult task, or
that some contributors are not legally allowed to transfer their
copyright.

Copyright assignment is irrelevant with respect to non-GNU ELPA. It is sort of the point. 

> 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.

> 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. 

 
> 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.  

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


reply via email to

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