Seeking input from developers: glibc copyright assignment policy.

[Siddhesh Poyarekar]

On 6/25/21 12:36 PM, Eli Zaretskii wrote:
> 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.

Fair enough, I can redact 'shared' to align with your interpretation 
because we're otherwise talking about the same thing.  It still doesn't 
change the crux of my point, that it is perfectly reasonable for someone 
to be picky about who they assign copyright to.

>> 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?

Nope, you've got it the other way around.  By making copyright 
assignment optional, we're stepping away from promoting anything at all. 
  The proposal does not discourage people from assigning code to the 
FSF; FSF assigned contributions are as welcome as those assigned to SFLC 
or the SFC or for that matter, using DCO.

We're not trying to convince GNU projects to stop requiring assignments 
either.  Other projects are free to operate the way they wish.  I agree 
Gnulib is in a bit of a sticky situation with the code that is shared 
with glibc, but it's not the first time that a GNU project would end up 
with code bases with multiple owners that are not FSF.  In fact, glibc 
is already in that situation.

As for my views, I'm happy to share them in a separate thread if you 
wish because they're orthogonal to this discussion.

>> 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.

When the assignment is mandatory, code contributions are as good as an 
association with the copyright holding organization, hence there is an 
engagement.

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

That's the thing; there are many who choose not to contribute for this 
precise reason and "we're better off without them" is not something I 
endorse in this context.

>>> 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.

Lawyers are not a collective, IP lawyers, less so.  I have spoken to and 
listened to multiple legal experts over the years to get their opinion 
on the subject and in my experience the opinion is quite divided and 
definitely more nuanced than A > B.  I made that conclusion for myself 
based on those opinions.

I think you're misconstruing my personal decision (which is what I have 
been stating all along) as the voice of the project.  I am not giving 
legal advice when stating my preference of DCO over copyright 
assignment, I am giving my preference.  The voice of the project, as the 
governance model stands now, is that of consensus with the final 
decision resting with the FSF stewards (based on majority) if consensus 
cannot be reached.

In other words, as a member of the glibc project I am voicing my opinion 
to contribute to the process of building consensus around the proposal.

>> 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.

I don't think there's any real evidence to claim that assignments are 
less leaky than DCO.  Just because one process involves reams of paper 
doesn't mean that it's better.

Siddhesh