Re: non-gnu elpa issue tracking

[Tim Cross <theophilusx@gmail.com>]

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

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

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