Copyright verification service

Copyright verification service

[Tim Cross]

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

in the past, there has been mention about the difficulty or manual aspect
of verifying whether someone has assigned copyright to the FSF. I'm
wondering if we couldn't improve this situation with a very simple web
service.

My thought is that you could have a web service where you submit an email
address and it returns either true or false if that email is associated
with someone who has assigned copyright to the FSF. This provides minimal
information, so should not be an issue wrt privacy and could potentially
make it easier for those maintaining ELPA (and perhaps Emacs core) to
verify if a submission is from someone who has assigned copyright.

If necessary, the service could also be locked down with some level of
authentication. Later, the service could possibly be incorporated into
semi-automated workflows i.e. you could possibly add a git commit hook
which added copyright status to the commit message etc.

The service could be very simple - could even be driven by simple file
lookup from a text file that is easy to update when new assignments are
made.

-- 
regards,

Tim

--
Tim Cross

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

Re: Copyright verification service

[Bastien]

Hi Tim,

I've toyed with this idea myself for a while.

I don't know if it is a good idea for the GNU project in general, but
as someone who sometimes need to check the copyright status of some
contributors for Org/Emacs, the current setup is fine for me.

Although, I don't think authentication would be optional as we should
by default assume that the list of signed contributors should be kept
private, shouldn't we?

If the authentication system is mandatory then it raises the larger
question of maintaining a system that needs security monitoring, and
I'm pretty sure the current resources are too scarce for this... but
maybe not.

2 cents,

-- 
 Bastien

Re: Copyright verification service

[Tim Cross]

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

On Mon, 25 May 2020 at 17:58, Bastien <bzg@gnu.org> wrote:

> Hi Tim,
>
> I've toyed with this idea myself for a while.
>
> I don't know if it is a good idea for the GNU project in general, but
> as someone who sometimes need to check the copyright status of some
> contributors for Org/Emacs, the current setup is fine for me.
>

I'm thinking more along the lines that we are successful in establishing an
ELPA repository which has a much higher number of packages than the current
situation. If we can establish processes that are reasonably efficient and
'low pain', more developers are likely to be prepared to have their package
in ELPA rather than MELPA. If this occurs, the current model of providing
push rights to the GNU Emacs repository for package developers will not
scale and there will be a higher level of maintenance burden placed on a
smaller team of maintainers who do have those rights.

>
> Although, I don't think authentication would be optional as we should
> by default assume that the list of signed contributors should be kept
> private, shouldn't we?
>

My idea is that the list does stay private. You cannot see/retrieve the
list. All you can do is submit an email address and it will come back with
either yes or no (ture/false etc).. You wold need to know the email address
before you can check copyright status. You cold add rate limiting to
prevent the service being hit with millions of addresses (i.e. someone
harvests all the email addresses from the mail list and then tries to
determine who has copyright assignment etc).

>
> If the authentication system is mandatory then it raises the larger
> question of maintaining a system that needs security monitoring, and
> I'm pretty sure the current resources are too scarce for this... but
> maybe not.
>
>
I agree. It is a great pity there isn't a GNU identity provider. I actually
think that would be a really good service in support of free software. If
the FSF was able to establish a stable and reliable identity provider, all
those sites which now offer login via google, facebook etc, could also
offer a free open alternative.

The big problem is, I don't believe the FSF has the resources or skills to
do service provisioning. The requirements to provide a reliable  service
offering are different enough from development of software applications
that a whole different group would likely be required. I do wonder if there
might be an established organisation who can embrace FSF philosophy and who
has the needed skill sets that would be able to provide such a service on
behalf of the FSF.  There are free and open implementations of identity
provider software out there, but nobody is offering it as a service,
effectively limiting users who do not want to use closed and potentially
evil providers from benefiting from the advantages such services can offer.
Either we have to use google, facebook, github etc service or we need to
provide our personal info to multiple services for direct access. A free
and open identity provider with strong privacy policy that embodies the FSF
philosophy is a critical piece of the puzzle which is currently missing.
The growth in service delivered technologies only makes this gap worse.



>
> --
regards,

Tim

--
Tim Cross

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

Re: Copyright verification service

[Clément Pit-Claudel]

On 25/05/2020 03.58, Bastien wrote:
> Hi Tim,
> 
> I've toyed with this idea myself for a while.
> 
> I don't know if it is a good idea for the GNU project in general, but
> as someone who sometimes need to check the copyright status of some
> contributors for Org/Emacs, the current setup is fine for me.
> 
> Although, I don't think authentication would be optional as we should
> by default assume that the list of signed contributors should be kept
> private, shouldn't we?

The API idea was discussed in depth two weeks ago, as part of the very long thread on packages not getting included in ELPA; see https://lists.gnu.org/archive/html/emacs-devel/2020-05/msg01909.html.  The conclusion was that email addresses are not private, since they appear in commits anyway.   rms said he would talk to the FSF sysadmins to see if something was feasible.

Clément.

Re: Copyright verification service

[Tim Cross]

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

On Tue, 26 May 2020 at 10:30, Clément Pit-Claudel <cpitclaudel@gmail.com>
wrote:

> On 25/05/2020 03.58, Bastien wrote:
> > Hi Tim,
> >
> > I've toyed with this idea myself for a while.
> >
> > I don't know if it is a good idea for the GNU project in general, but
> > as someone who sometimes need to check the copyright status of some
> > contributors for Org/Emacs, the current setup is fine for me.
> >
> > Although, I don't think authentication would be optional as we should
> > by default assume that the list of signed contributors should be kept
> > private, shouldn't we?
>
> The API idea was discussed in depth two weeks ago, as part of the very
> long thread on packages not getting included in ELPA; see
> https://lists.gnu.org/archive/html/emacs-devel/2020-05/msg01909.html.
> The conclusion was that email addresses are not private, since they appear
> in commits anyway.   rms said he would talk to the FSF sysadmins to see if
> something was feasible.
>
> OK, thanks for the info. It i hard to keep on top of all the threads about
> ELPA at the moment.



-- 
regards,

Tim

--
Tim Cross

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

Re: Copyright verification service

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > in the past, there has been mention about the difficulty or manual aspect
  > of verifying whether someone has assigned copyright to the FSF. I'm
  > wondering if we couldn't improve this situation with a very simple web
  > service.

I've asked the FSF staff to discuss setting up something like this.

-- 
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: Copyright verification service

[Eli Zaretskii]

> From: Tim Cross <theophilusx@gmail.com>
> Date: Tue, 26 May 2020 10:02:26 +1000
> Cc: Emacs developers <emacs-devel@gnu.org>
> 
> My idea is that the list does stay private. You cannot see/retrieve the list. All you can do is submit an email
> address and it will come back with either yes or no (ture/false etc).. You wold need to know the email
> address before you can check copyright status.

Richard is working with the FSF stuff on this, but AFAIU the response
cannot be a binary YES/NO result, it must be able to return a 3rd
value, meaning "human investigation is required".  I don't know if you
ever saw the copyright list, but some entries there are not very
trivial for a program to process, since they include various
conditions that are written in free-text format which would not be
simple for a program to parse and apply.

Re: Copyright verification service

[Tim Cross]

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

On Wed, 27 May 2020 at 00:37, Eli Zaretskii <eliz@gnu.org> wrote:

> > From: Tim Cross <theophilusx@gmail.com>
> > Date: Tue, 26 May 2020 10:02:26 +1000
> > Cc: Emacs developers <emacs-devel@gnu.org>
> >
> > My idea is that the list does stay private. You cannot see/retrieve the
> list. All you can do is submit an email
> > address and it will come back with either yes or no (ture/false etc)..
> You wold need to know the email
> > address before you can check copyright status.
>
> Richard is working with the FSF stuff on this, but AFAIU the response
> cannot be a binary YES/NO result, it must be able to return a 3rd
> value, meaning "human investigation is required".  I don't know if you
> ever saw the copyright list, but some entries there are not very
> trivial for a program to process, since they include various
> conditions that are written in free-text format which would not be
> simple for a program to parse and apply.
>

That wouldn't be an issue - you can easily define the semantics to whatever
is needed. It may also be necessary to transform/normalize the source data
and you could even set things up so that if a manual check needs to be made
for a particular email address, once that check has been performed, add
that email address with the appropriate value so that it doesn't need to be
done again. The first object here is to make the processes easier and a
good example of the 80/20 rule.
-- 
regards,

Tim

--
Tim Cross

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

Re: Copyright verification service

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

     > rms said he would talk to the FSF sysadmins to see if something was feasible.

I have got no response so far.  In a few days it will be time for
me to ask again.

-- 
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: Copyright verification service

[Bastien]

Hi Clément,

Clément Pit-Claudel <cpitclaudel@gmail.com> writes:

> On 25/05/2020 03.58, Bastien wrote:
>> Hi Tim,
>> 
>> I've toyed with this idea myself for a while.
>> 
>> I don't know if it is a good idea for the GNU project in general, but
>> as someone who sometimes need to check the copyright status of some
>> contributors for Org/Emacs, the current setup is fine for me.
>> 
>> Although, I don't think authentication would be optional as we should
>> by default assume that the list of signed contributors should be kept
>> private, shouldn't we?
>
> The API idea was discussed in depth two weeks ago, as part of the very
> long thread on packages not getting included in ELPA; see
> https://lists.gnu.org/archive/html/emacs-devel/2020-05/msg01909.html.

Thanks for the pointer.

> The conclusion was that email addresses are not private, since they
> appear in commits anyway.  

Well, privacy is about the *link* between an email and a person.

If I am using an address like batman@pm.me for my contributions (i.e.
for both the emails I send to a mailing list and for my patches), then
only those who can access the copyright list know I am Bruce Wayne and
I trust them not to disclose this information publicly.

So the question seems rather: shall the FSF preserve the possibility
for someone to consider his copyright assignment as private info?

I think the FSF should let contributors decide whether they want their
assignment to be public or not.

> rms said he would talk to the FSF sysadmins to see if something was
> feasible.

OK, thanks.

-- 
 Bastien

Re: Copyright verification service

[Clément Pit-Claudel]

On 01/06/2020 02.59, Bastien wrote:
> If I am using an address like batman@pm.me for my contributions (i.e.
> for both the emails I send to a mailing list and for my patches), then
> only those who can access the copyright list know I am Bruce Wayne and
> I trust them not to disclose this information publicly.

Why would they? The proposal is to build an API that responds to queries like "does batman@pm.me have an assignment on file?", not "who is batman@pm.me?"

Re: Copyright verification service

[Bastien]

Clément Pit-Claudel <cpitclaudel@gmail.com> writes:

> On 01/06/2020 02.59, Bastien wrote:
>> If I am using an address like batman@pm.me for my contributions (i.e.
>> for both the emails I send to a mailing list and for my patches), then
>> only those who can access the copyright list know I am Bruce Wayne and
>> I trust them not to disclose this information publicly.
>
> Why would they? The proposal is to build an API that responds to
> queries like "does batman@pm.me have an assignment on file?", not "who
> is batman@pm.me?"

Then that's fine!  I thought it was an API to access info currently
found in the text file.  Thanks for the precision.

-- 
 Bastien