Re: Seeking input from developers: glibc copyright assignment policy.

[Eli Zaretskii <eliz@gnu.org>]

> Cc: libc-alpha@sourceware.org
> From: Siddhesh Poyarekar <siddhesh@gotplt.org>
> Date: Fri, 25 Jun 2021 07:53:49 +0530
> 
> On 6/25/21 1:00 AM, Eli Zaretskii wrote:
> > AFAIU, the copyright assignment to the FSF doesn't contradict (2),
> > because the assignment agreement explicitly grants the copyright back
> > to you.  Quote:
> > 
> >    (d) FSF agrees to grant back to Developer, and does hereby grant,
> >    nonexclusive, royalty free, fully paid up and non-cancellable
> >    worldwide rights to use the Works (i.e., Developer's changes and/or
> >    enhancements, not the Program that they enhance), as Developer sees
> >    fit; this grant back does not limit FSF's rights and public rights
> >    acquired through this agreement.
> 
> A grant back is not nearly the same thing.

I don't follow.  You said:

> (2) contributors who prefer to retain ownership of their content for
> various reasons

I'm showing text from the assignment agreement that IMO clearly says
the developer retains all the rights.  IOW, as long as the developer
doesn't prevent the FSF from using the changes as they see fit, the
developer can do anything with the changes, including distributing
them under any license the developer wants.  Why doesn't this satisfy
your point (2)?

> It still needs trust in the organization to represent my values.

I think this is (3), not (2).

And I don't really understand what values are being alluded to here.
The FSF is an organization whose only purpose is supporting and
promoting Free Software; as such, the only relevant values (or should
I say "value", singular) is the support and promotion of Free
Software.  Anything else is not relevant to the FSF and our relations
with it, and can only be some private values or views of some FSF
members.  What does this have to do with the copyright assignment for
a contribution to a GNU project such as glibc?

> > The DCO allows to make the presentation on behalf of third parties,
> > which were involved in writing the code, but are not part of the
> > contribution dialog.  It also hand-waves over the need to involve the
> > employer in the process, to make sure they won't claim the copyright.
> > So the risk of admitting code whose copyright could later be
> > challenged is greater.
> 
> The assignment process does not *need* an employer's involvement so I'm 
> not convinced that a developer being dismissive or purposefully 
> dishonest won't do so in case of an assignment.

The DCO text practically tells the developer not to worry about "this
nonsense", and just say things "to the best of his/her knowledge".  It
doesn't even explain the purpose of the declarations in the DCO and
how they will be used by the project.  For example, the crucial
importance of the information veracity for a possible future
litigation is never mentioned.  So even if the developer wants to
DTRT, they won't know what is and isn't important in their
declaration, and thus will not be able to make sure the important
information is verified and correct.