emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Why are so many great packages not trying to get included in GNU Ema


From: Clément Pit-Claudel
Subject: Re: Why are so many great packages not trying to get included in GNU Emacs?
Date: Tue, 12 May 2020 15:48:01 -0400
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0

On 12/05/2020 13.39, Eli Zaretskii wrote:
>> Cc: address@hidden, address@hidden,
>> address@hidden, address@hidden, address@hidden,
>> address@hidden, address@hidden From: Clément
>> Pit-Claudel <address@hidden> Date: Tue, 12 May 2020 13:26:37
>> -0400
>> 
>>>> My proposal is that this API should be the FSF signing public
>>>> keys
>>> 
>>> I don't think I follow.  FSF is not a piece of software and not
>>> an API.  It is an organization.  How can an organization be an
>>> API?
>> 
>> With the scheme I propose, you don't need an API any more, I think
>> (for properly signed commits).
> 
> Now I'm completely confused: what scheme are you proposing?  Can you 
> describe it in more detail?

Yes, of course.

One problem with have when integrating external packages is that we have many 
commits whose copyright status is unclear: who wrote them? Does the FSF have a 
copyright assignment for that person?

Currently, the way you answer such a question is that you look at the commit, 
try to determine the author, and check a list of people who have assigned 
copyright to see if the author is in it.

This process is cumbersome, because few have access to the list.  One way to 
make it smoother is to add an API that gives access to that list.  

Another strategy, which doesn't solve the problem for past commits but could 
help for future commits, is to embed that information into commits.  Something 
like adding a line in the commit saying "I-have-assigned-copyright: Yes".

Of course, just adding that line doesn't prove anything: we want to make sure 
that we do have an assignment for that commit.
So, instead of adding a line, the author could sign the commit with their PGP 
key, saying "all these changes are mine or from sources owned by FSF" (a bit 
like a developer certificate of origin).

Now the problem is reduced to "does the author with this PGP key have an 
assignment on file"?  But this question can be answered in a decentralized way 
(no need for an API): the FSF can just sign keys instead.

Indeed, currently, when you assign copyright to the FSF, you sign a document 
with a GPG key.  The FSF could sign that key to indicate "we have received 
copyright papers for this author".

Then, to verify "do we have papers for the author of this commit", anyone could 
check "is this commit signed with a key signed by the FSF"?

As a package maintainer, I wouldn't have to ever check fencepost to verify 
assignments when I receive patches.  Instead, the way I check that someone has 
an assignment on file is by asking them to sign their commit with an FSF-signed 
key.

Does it make sense?
Clément.  





reply via email to

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