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 12:17:57 +0530
> 
> On 6/25/21 11:56 AM, Eli Zaretskii wrote:
> > 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)?
> 
> Sorry I should have been clearer, I meant to say that an assignment with 
> a grant back implies a shared ownership, which is different from wanting 
> exclusive ownership.  It's perfectly reasonable for someone to be picky 
> about who they share ownership with.

I don't see how the above means shared ownership.  My interpretation
is that the developer owns the changes, and the FSF owns the changes
contributed to the project, but they each one own their separate copy
separately and independently.  "Shared" means what one owner does
affects the other, whereas in this case the text of the assignment
explicitly says there's no such dependencies.

> > 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?
> 
> That's for me to decide, no?  :)

It's for you to decide, but when you promote those decisions for
others to follow, and actively convince GNU projects to stop requiring
the CLA, presumably for those same reasons, it is only reasonable for
me and others to ask about the details of your views on this, no?

> Different people take a different view of the kinds of values they
> would attach to an engagement and it may differ with the nature of
> engagement.

There's no engagement here.  You give the FSF some extra rights
related to the code, that's all.  Those rights don't mean anything
tangible for the developers anyway.

If you _really_ don't want any engagement, don't contribute your code
at all.  Because the code contribution is the important part here.

> > 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.
> 
> I don't think that difference matters in practice

Based on what?  Are you a lawyer who is proficient in this area?  I'm
not, so I listen to those who are, and they say it does matter.

> definitely not enough to create an elaborate mechanism that is
> similarly leaky.

We are in the business of engineering, not exact science.  Engineering
is a discipline based on compromises: perfect solutions are rarely
available, so we choose the least imperfect ones.  "Similarly leaky"
may be rigorously accurate, but if one is less "leaky" than the other,
the sensible solution is to prefer the less "leaky" one.