Seeking input from developers: glibc copyright assignment policy.

[Eli Zaretskii]

> Cc: libc-alpha@sourceware.org
> From: Siddhesh Poyarekar <siddhesh@gotplt.org>
> Date: Fri, 25 Jun 2021 14:27:44 +0530
> 
> 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.

Anyone can be picky about anything, but it is important that others
realize that people are picky for reasons that only make sense to
those picky people.  That's why this discussion is important: to
encourage others invest their own thought and considerations into
their own decisions about this.

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

That's tongue-in-cheek, Siddhesh.  I've read enough of your posts on
this subject to conclude that they are not really neutral.  Even in
this thread, you are clearly saying that the DCO isn't inferior to the
CLA, which actually means it is better, because it's easier to use.

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

No.  You contribute code to a project, not to the FSF.  The FSF are
the ones who do the clerical work, that's all.

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

IME, many people who choose not to contribute for this reason don't
understand the essence of the CLA, and sometimes are brainwashed.
They've never read the actual CLA text, let alone thought about its
meaning and effects.  Patiently educating these people about the facts
goes a long way towards eliminating their objections.

Yes, it's easier to just remove the requirement for the CLA, but doing
so comes with risks that aren't negligible.

> >> 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'm quite sure you've heard some say CLA > DCO, and others CLA ≅ DCO.
I don't think you've heard anyone saying DCO > CLA.  If your
conclusion is based on any unbiased considering of such opinions, the
result should be obvious, and it isn't "the difference doesn't
matter", let alone "doesn't matter in practice".

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

That is an important clarification, and I wish that you (and others,
including myself) repeated it more frequently in these discussions.
Our opinions may have significant weight when we talk about software
development of our respective projects, but their weight in matters of
legal paperwork and moral values is not higher (nor lower) than those
of any other person.  We have no real authority in these matters, not
unless we can present some relevant credentials which say otherwise.
When such credentials are absent, people should not follow our views
just because we have a high commit count in our repositories, they
should make up their own minds based on the information they seek and
find, not based on our views and opinions.

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

I think it's easy to see that the CLA is less leaky by reading the
text, and also based on the form that the contributors are requested
to fill.