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

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

[Bruno Haible]

Accepting DCO-based contributions has legal risks (see [1] and others).

The cited advantage of the DCO policy is that it promises "future growth
and vibrancy" [2].

How would this advantage work in practice? It would mean that an
occasional contributor, after contributing a patch, would not have to
wait a longer time until their patch is accepted. Thus increasing the
motivation of the contributor to contribute again.

So, you have occasional contributors, for whom the DCO can be an
advantage. And you have regular contributors, who can be expected to
do the paperwork with the FSF; it's a one-time thing.

Occasional contributors will typically not start their journey with
contributions to the dynamic loader, the thread library, or the regex
engine.

Here is a proposal to keep the advantage for most occasional contributors,
while at the same time reducing legal risk for the important parts of
glibc.

1) Define a "core" of glibc to be the set of files which you would not
   want to see as the subject of "this file contains a copyright violation,
   you must remove it" claim by some company, university, or ill-behaving
   individual.

2) Allow DCO contributions only to non-core files of glibc.

This means, occasional contributors would be able to contribute with DCO
to things like unit tests, iconv conversion modules, assembly-language
implementations for <string.h> functions, the nscd daemon, and such.
But would be required to exchange papers for legally significant [3]
contributions to "core" areas (that IMO would include the dynamic loader,
the thread library, and the regex engine).

Such a policy would provide a balance between
  - motivating contributors during their first contributions, and
  - avoiding legal risk.

Bruno

[1] https://lists.gnu.org/archive/html/bug-gnulib/2021-06/msg00080.html
[2] https://sourceware.org/pipermail/libc-alpha/2021-June/127616.html
[3] https://www.gnu.org/prep/maintain/html_node/Legally-Significant.html

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

[Siddhesh Poyarekar]

On 6/23/21 6:34 AM, Bruno Haible wrote:
> Accepting DCO-based contributions has legal risks (see [1] and others).
> 
> The cited advantage of the DCO policy is that it promises "future growth
> and vibrancy" [2].
> 
> How would this advantage work in practice? It would mean that an
> occasional contributor, after contributing a patch, would not have to
> wait a longer time until their patch is accepted. Thus increasing the
> motivation of the contributor to contribute again.
> 
> So, you have occasional contributors, for whom the DCO can be an
> advantage. And you have regular contributors, who can be expected to
> do the paperwork with the FSF; it's a one-time thing.

For me it is inclusion of (1) occasional contributors who may fix a bug 
that's bothering them and walk away (2) contributors who prefer to 
retain ownership of their content for various reasons and (3) 
contributors who do not wish to assign copyright to the FSF for various 
reasons.

I, as a regular contributor belong to a mix of 2 and 3.  I would 
generally prefer to retain copyright to my work unless it is done at the 
behest of my employer (in which case they deservedly own it since they 
pay me for it) but can be persuaded to assign copyright to an 
organization I trust to represent my values.

> Occasional contributors will typically not start their journey with
> contributions to the dynamic loader, the thread library, or the regex
> engine.

If only that were true.  In my experience we have had more occasional 
contributors fixing problems that bother them in various 'core' 
components rather than tests and documentation.

> Here is a proposal to keep the advantage for most occasional contributors,
> while at the same time reducing legal risk for the important parts of
> glibc.
> 
> 1) Define a "core" of glibc to be the set of files which you would not
>     want to see as the subject of "this file contains a copyright violation,
>     you must remove it" claim by some company, university, or ill-behaving
>     individual.
> 
> 2) Allow DCO contributions only to non-core files of glibc.
> 
> This means, occasional contributors would be able to contribute with DCO
> to things like unit tests, iconv conversion modules, assembly-language
> implementations for <string.h> functions, the nscd daemon, and such.
> But would be required to exchange papers for legally significant [3]
> contributions to "core" areas (that IMO would include the dynamic loader,
> the thread library, and the regex engine).
> 
> Such a policy would provide a balance between
>    - motivating contributors during their first contributions, and
>    - avoiding legal risk.

All of this assumes that a copyright assignment is somehow superior to 
DCO when it comes to legal defense and that the latter is just a 
compromise.  I am not convinced that it is.

Siddhesh

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

[Eli Zaretskii]

> From: siddhesh@gotplt.org (Siddhesh Poyarekar)
> Date: Wed, 23 Jun 2021 08:49:24 +0530
> 
> For me it is inclusion of (1) occasional contributors who may fix a bug 
> that's bothering them and walk away (2) contributors who prefer to 
> retain ownership of their content for various reasons and (3) 
> contributors who do not wish to assign copyright to the FSF for various 
> reasons.
> 
> I, as a regular contributor belong to a mix of 2 and 3.  I would 
> generally prefer to retain copyright to my work unless it is done at the 
> behest of my employer (in which case they deservedly own it since they 
> pay me for it) but can be persuaded to assign copyright to an 
> organization I trust to represent my values.

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.

> All of this assumes that a copyright assignment is somehow superior to 
> DCO when it comes to legal defense and that the latter is just a 
> compromise.  I am not convinced that it is.

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.

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

[Siddhesh Poyarekar]

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.  It still needs trust in the 
organization to represent my values.

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

Siddhesh

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

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

[Siddhesh Poyarekar]

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.

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

That's for me to decide, 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.

> 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, definitely not enough 
to create an elaborate mechanism that is similarly leaky.

 > Oh, and talking about dishonest contributors is not useful.  I'm
 > talking about the honest ones.  If someone wants to lie about the

Agreed, I mentioned that case only for completeness.

Siddhesh

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

Re: 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

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

[Siddhesh Poyarekar]

On 6/25/21 2:27 PM, Siddhesh Poyarekar wrote:
> 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.

... actually I should correct myself based on Florian's comment.  The 
copyright ownership does get transferred to the assignee and the 
assigner is granted back an unhindered, unlimited *use* license.

Siddhesh

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

[Eli Zaretskii]

> From: Siddhesh Poyarekar <siddhesh@gotplt.org>
> Cc: libc-alpha@sourceware.org
> Date: Fri, 25 Jun 2021 15:13:57 +0530
> 
> ... actually I should correct myself based on Florian's comment.  The 
> copyright ownership does get transferred to the assignee and the 
> assigner is granted back an unhindered, unlimited *use* license.

"Use" that includes the rights to distribute under any conditions.
How is this different from ownership?

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

[Florian Weimer]

* Eli Zaretskii via Libc-alpha:

>> From: Siddhesh Poyarekar <siddhesh@gotplt.org>
>> Cc: libc-alpha@sourceware.org
>> Date: Fri, 25 Jun 2021 15:13:57 +0530
>> 
>> ... actually I should correct myself based on Florian's comment.  The 
>> copyright ownership does get transferred to the assignee and the 
>> assigner is granted back an unhindered, unlimited *use* license.
>
> "Use" that includes the rights to distribute under any conditions.
> How is this different from ownership?

For example, you cannot contribute the code to another project that also
requires copyright assignment.  This issue has come up in practice with
the Bacula project, where many contributors assigned their changes
twice, to different organizations.

Furthermore, it's unclear to me if you can contribute the code to a
project that gives recipients the right to sublicense.

Thanks,
Florian

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

[Siddhesh Poyarekar]

On 6/25/21 5:02 PM, Eli Zaretskii wrote:
>> From: Siddhesh Poyarekar <siddhesh@gotplt.org>
>> Cc: libc-alpha@sourceware.org
>> Date: Fri, 25 Jun 2021 15:13:57 +0530
>>
>> ... actually I should correct myself based on Florian's comment.  The
>> copyright ownership does get transferred to the assignee and the
>> assigner is granted back an unhindered, unlimited *use* license.
> 
> "Use" that includes the rights to distribute under any conditions.
> How is this different from ownership?


Nope, use and distribute are two different things.

Siddhesh

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

[Florian Weimer]

* Siddhesh Poyarekar:

> On 6/25/21 5:02 PM, Eli Zaretskii wrote:
>>> From: Siddhesh Poyarekar <siddhesh@gotplt.org>
>>> Cc: libc-alpha@sourceware.org
>>> Date: Fri, 25 Jun 2021 15:13:57 +0530
>>>
>>> ... actually I should correct myself based on Florian's comment.  The
>>> copyright ownership does get transferred to the assignee and the
>>> assigner is granted back an unhindered, unlimited *use* license.
>> "Use" that includes the rights to distribute under any conditions.
>> How is this different from ownership?
>
> Nope, use and distribute are two different things.

“Use” is a technical term for exploiting rights under copyright.  Such
rights include making copies and distributing them.

Thanks,
Florian

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

[Siddhesh Poyarekar]

On 6/25/21 5:44 PM, Florian Weimer wrote:
> “Use” is a technical term for exploiting rights under copyright.  Such
> rights include making copies and distributing them.

Interesting, so does that also give rights to re-license for 
distribution?  I was convinced otherwise.

Siddhesh

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

[Florian Weimer]

* Siddhesh Poyarekar:

> On 6/25/21 5:44 PM, Florian Weimer wrote:
>> “Use” is a technical term for exploiting rights under copyright.  Such
>> rights include making copies and distributing them.
>
> Interesting, so does that also give rights to re-license for
> distribution?  I was convinced otherwise.

I have no idea.  I don't even know if the FSF intends to grant a
sublicense.  U.S. courts apparently have developed the concept of an
implied sublicense, but it's unclear whether the preconditions for that
have been met in our case.

Thanks,
Florian

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

[Siddhesh Poyarekar]

On 6/25/21 6:03 PM, Florian Weimer wrote:
> * Siddhesh Poyarekar:
> 
>> On 6/25/21 5:44 PM, Florian Weimer wrote:
>>> “Use” is a technical term for exploiting rights under copyright.  Such
>>> rights include making copies and distributing them.
>>
>> Interesting, so does that also give rights to re-license for
>> distribution?  I was convinced otherwise.
> 
> I have no idea.  I don't even know if the FSF intends to grant a
> sublicense.  U.S. courts apparently have developed the concept of an
> implied sublicense, but it's unclear whether the preconditions for that
> have been met in our case.

The thing is, if I have an implied, unlimited right to distribute then I 
have the right to dictate the terms of the distribution.  That does not 
sound correct.

I'm unable to find a reference that says that 'use' implies 
distribution.  The copyright law gives exclusive distribution rights to 
the copyright holder, so I would have thought that the distribution 
aspect ought to be made explicit.

In fact, the FSF agreement explicitly mentions "use, license and 
distribute" in the context of rights that the FSF gains from the 
assignment, among other things.

Siddhesh

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

[Eli Zaretskii]

> Cc: Eli Zaretskii <eliz@gnu.org>, libc-alpha@sourceware.org
> From: Siddhesh Poyarekar <siddhesh@gotplt.org>
> Date: Fri, 25 Jun 2021 18:18:55 +0530
> 
> >> Interesting, so does that also give rights to re-license for
> >> distribution?  I was convinced otherwise.
> > 
> > I have no idea.  I don't even know if the FSF intends to grant a
> > sublicense.  U.S. courts apparently have developed the concept of an
> > implied sublicense, but it's unclear whether the preconditions for that
> > have been met in our case.
> 
> The thing is, if I have an implied, unlimited right to distribute then I 
> have the right to dictate the terms of the distribution.  That does not 
> sound correct.
> 
> I'm unable to find a reference that says that 'use' implies 
> distribution.

One reference I'm aware of is this:

  https://www.fsf.org/bulletin/2014/spring/copyright-assignment-at-the-fsf

It explicitly says the developer can "modify, share, and sublicense
their own work under terms of their choice".

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

[Siddhesh Poyarekar]

On 6/25/21 7:14 PM, Eli Zaretskii wrote:
> One reference I'm aware of is this:
> 
>    https://www.fsf.org/bulletin/2014/spring/copyright-assignment-at-the-fsf
> 
> It explicitly says the developer can "modify, share, and sublicense
> their own work under terms of their choice".
> 

That's a claim from the FSF, which does not to correspond to the text of 
the agreement; I don't know if that can be viewed as a clarification. 
If I looked at the same article in a different context, it appears to me 
that "use" is distinct enough from "modify, share and sublicense" that 
the latter needs to be spelled out explicitly.

Siddhesh

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

[Eli Zaretskii]

> Cc: fweimer@redhat.com, libc-alpha@sourceware.org
> From: Siddhesh Poyarekar <siddhesh@gotplt.org>
> Date: Fri, 25 Jun 2021 19:36:30 +0530
> 
> On 6/25/21 7:14 PM, Eli Zaretskii wrote:
> > One reference I'm aware of is this:
> > 
> >    https://www.fsf.org/bulletin/2014/spring/copyright-assignment-at-the-fsf
> > 
> > It explicitly says the developer can "modify, share, and sublicense
> > their own work under terms of their choice".
> 
> That's a claim from the FSF, which does not to correspond to the text of 
> the agreement; I don't know if that can be viewed as a clarification. 

Since those are the guys to whom the assignment goes, I think their
claim does have some weight.  And note the authors of that article.

But if that's insufficient, whose opinion will satisfy you?

> If I looked at the same article in a different context, it appears to me 
> that "use" is distinct enough from "modify, share and sublicense" that 
> the latter needs to be spelled out explicitly.

But they are all allowed, according to the article, so why does it
matter?

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

[Siddhesh Poyarekar]

On 6/26/21 12:01 PM, Eli Zaretskii wrote:
>> That's a claim from the FSF, which does not to correspond to the text of
>> the agreement; I don't know if that can be viewed as a clarification.
> 
> Since those are the guys to whom the assignment goes, I think their
> claim does have some weight.  And note the authors of that article.
> 
> But if that's insufficient, whose opinion will satisfy you?

Even if I concede to the idea that their claim has some weight , they do 
not explicitly say that the "use" in our agreements implies distribution 
rights.  Also, how much legal weight does a website article (regardless 
of its source) have over an agreement, especially one which says that it 
most likely never will be supplemented by another agreement?

To flip it around, if I as the second party to that agreement, claim 
that the agreement means that I am entitled to compensation for my 
patches or some other ridiculous claim, does that claim have weight?

It could still be that "use" is a technical legal term as Florian claims 
and I'll be happy to concede the point if I'm pointed to a general 
reference that says that.

>> If I looked at the same article in a different context, it appears to me
>> that "use" is distinct enough from "modify, share and sublicense" that
>> the latter needs to be spelled out explicitly.
> 
> But they are all allowed, according to the article, so why does it
> matter?

Because an article is not a legal document.

Siddhesh

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

[Eli Zaretskii]

> Cc: fweimer@redhat.com, libc-alpha@sourceware.org
> From: Siddhesh Poyarekar <siddhesh@gotplt.org>
> Date: Mon, 28 Jun 2021 09:41:03 +0530
> 
> On 6/26/21 12:01 PM, Eli Zaretskii wrote:
> >> That's a claim from the FSF, which does not to correspond to the text of
> >> the agreement; I don't know if that can be viewed as a clarification.
> > 
> > Since those are the guys to whom the assignment goes, I think their
> > claim does have some weight.  And note the authors of that article.
> > 
> > But if that's insufficient, whose opinion will satisfy you?
> 
> Even if I concede to the idea that their claim has some weight , they do 
> not explicitly say that the "use" in our agreements implies distribution 
> rights.  Also, how much legal weight does a website article (regardless 
> of its source) have over an agreement, especially one which says that it 
> most likely never will be supplemented by another agreement?

AFAIU, that's how things are in the legal business: you get the
opinions of the experts and work with that.

> To flip it around, if I as the second party to that agreement, claim 
> that the agreement means that I am entitled to compensation for my 
> patches or some other ridiculous claim, does that claim have weight?

On which parts of the document will you base this ridiculous claim?

> >> If I looked at the same article in a different context, it appears to me
> >> that "use" is distinct enough from "modify, share and sublicense" that
> >> the latter needs to be spelled out explicitly.
> > 
> > But they are all allowed, according to the article, so why does it
> > matter?
> 
> Because an article is not a legal document.

Since legal documents rarely change, reasonable interpretation by
experts is what you have to do with.  It is very strange to hear what
you say in this case, given that no one else seems to be of the same
opinion, everyone else interpret this as a grant of unlimited
nonexclusive rights.  It almost sounds like you don't _want_ the
language to mean that.

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

[Siddhesh Poyarekar]

On 6/28/21 5:31 PM, Eli Zaretskii wrote:
>> To flip it around, if I as the second party to that agreement, claim
>> that the agreement means that I am entitled to compensation for my
>> patches or some other ridiculous claim, does that claim have weight?
> 
> On which parts of the document will you base this ridiculous claim?

It was a general question, not specific to the document to get across 
the point that one cannot make generally acceptable claims that way. 
You can trust them if you want, but you need to be aware that they can 
be disputed.

>>>> If I looked at the same article in a different context, it appears to me
>>>> that "use" is distinct enough from "modify, share and sublicense" that
>>>> the latter needs to be spelled out explicitly.
>>>
>>> But they are all allowed, according to the article, so why does it
>>> matter?
>>
>> Because an article is not a legal document.
> 
> Since legal documents rarely change, reasonable interpretation by
> experts is what you have to do with.  It is very strange to hear what
> you say in this case, given that no one else seems to be of the same
> opinion, everyone else interpret this as a grant of unlimited
> nonexclusive rights.  It almost sounds like you don't _want_ the
> language to mean that.

I too have been worried that I'm the only one publicly making this 
interpretation.  This is especially because I too, like you had 
incorrectly assumed that the grant back returned the same unlimited 
rights to me as part of the assignment process; I even retracted that 
upthread after Florian's comment and subsequent reading.

And now that I think of it (and it's pretty much been front and centre 
in my head all weekend), I remember at least one entity I have worked 
with in the past having made this interpretation, specifically with 
respect to the FSF agreement and making sure they worked around it.  I 
did not quite understand it then and assumed it to be paranoia.

To be clear, I don't doubt the FSF's intention with respect to the 
agreement.  I have no reason to believe that they'll misuse the 
assignment not do I have any interest in relicensing code I have 
assigned to the FSF either directly or otherwise.  What I am trying to 
get across however is that there's no canonical interpretation.

Siddhesh

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

[Phil Blundell]

On Mon, Jun 28, 2021 at 06:36:21PM +0530, Siddhesh Poyarekar wrote:
> I too have been worried that I'm the only one publicly making this
> interpretation.

Just to jump in on that particular point, I don't think you should assume
that everybody else is firmly wedded to the opposite interpretation.  My
own view on that is that the situation is ambiguous and I suspect we will
never find out for sure until/unless someone ends up litigating the point 
and a court has to render an opinion.

But equally, I am not too bothered about it because the answer doesn't
seem to be directly germane to the point at hand.  Personally I have 
already signed an "all future changes" assignment to the FSF in respect 
of my changes to glibc and, although it's probably true that my opinion 
of the FSF as an organisation has shifted slightly in the quarter of a 
century since I originally signed the paperwork, I'm not sufficiently 
exercised about the situation to consider trying to change anything.

Even for new contributors I'm not sure that the requirement to assign
copyright to the FSF represents a huge barrier in itself.  I haven't
noticed a large number of would-be contributors mention that as something
that's a deal-breaker for them.  What *does* seem to be an issue in
practice is the associated requirement to get your employer / university
to disclaim their own interest in the changes and I have the impression
that this is where the majority of people who get stuck come to grief.

I think it's already been noted that glibc already contains code which
belongs to multiple copyright holders and there doesn't seem to be any
realistic prospect of relicensing the whole library regardless of what
happens with future contributions.  

So, as far as I can tell, the debate really seems to boil down to the 
risk of a DCO'd submission later turning out to include a copyright bomb 
if some organisation or individual were to come out of the woodwork and 
assert ownership of it.  And more specifically, whether we as a project
feel that this increased risk is justified by the removal of a roadblock
to future contributors.

My own view is that the risk, although not zero, is still small enough
to be tolerable and it would be outweighed by the benefit of not seeming
to throw obstacles in the way of would-be contributors.

I'm not sure that discussing the finer nuances of exactly what rights the
FSF does or doesn't grant back as part of a copyright assignment really
moves us any further forward.  Any would-be contributor for whom that's
an issue is going to have to make their own mind up about it anyway
irrespective of what consensus we reach here about the "correct" reading
of the license text.

p.

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

[Eli Zaretskii]

> Cc: fweimer@redhat.com, libc-alpha@sourceware.org
> From: Siddhesh Poyarekar <siddhesh@gotplt.org>
> Date: Mon, 28 Jun 2021 18:36:21 +0530
> 
> To be clear, I don't doubt the FSF's intention with respect to the 
> agreement.  I have no reason to believe that they'll misuse the 
> assignment not do I have any interest in relicensing code I have 
> assigned to the FSF either directly or otherwise.  What I am trying to 
> get across however is that there's no canonical interpretation.

If the FSF interpret that in this way, then that _is_ the canonical
interpretation.

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

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

[Siddhesh Poyarekar]

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

It's not, the comparison is a lot more nuanced than binary comparisons. 
  I can understand someone concluding that CLAs are superior for their 
risk/benefit tolerance, but I don't agree with them.  I have concluded 
for myself (and projects I would create myself) that DCO is adequate for 
all practical purposes.

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

Agreed, I am definitely not in the business of giving legal advice and 
my opinions on that are my own.

Siddhesh

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

[Florian Weimer]

* Eli Zaretskii via Libc-alpha:

> I'm showing text from the assignment agreement that IMO clearly says
> the developer retains all the rights.

No, the developer gives up copyright ownership.  This has real legal
consequences, and it is quite different from a broad-ranging license to
use the contributions.  If the FSF wanted the latter, it could ask for
precisely that, but instead it asks for full ownership.

Apart from the recent actions of the FSF that are so difficult to
understand, there is also a glibc-specific aspect here: The FSF is
ignoring large-scale LGPL infringement that comes with incorrect use of
container technology.  (At the very least, publishing a container image
with glibc in it requires certain legal notices according to the LGPL
terms, and all binaries linked against glibc must be re-linkable against
a changed glibc.)  This has reached such a degree that distributors of
container images might legally assume that the FSF has waived any and
all LGPL requirements, which the FSF can do as the copyright owner.  If
true, only an influx of additional copyright owners for glibc can
preserve the (limited) copyleft nature of glibc.

Thanks,
Florian

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

[Eli Zaretskii]

> From: Florian Weimer <fweimer@redhat.com>
> Cc: Siddhesh Poyarekar <siddhesh@gotplt.org>,  Eli Zaretskii <eliz@gnu.org>
> Date: Fri, 25 Jun 2021 09:24:51 +0200
> 
> * Eli Zaretskii via Libc-alpha:
> 
> > I'm showing text from the assignment agreement that IMO clearly says
> > the developer retains all the rights.
> 
> No, the developer gives up copyright ownership.

I don't understand what that means, sorry.  The text says I can do
anything and everything I want with the code, except interfering with
the FSF's use of that code.  So what exactly did I give up?

> This has real legal consequences, and it is quite different from a
> broad-ranging license to use the contributions.  If the FSF wanted
> the latter, it could ask for precisely that, but instead it asks for
> full ownership.

I looked up all the instances of "owner" and "ownership" in the CLA
text, and couldn't find where they ask for "full ownership".  What did
I miss?

> Apart from the recent actions of the FSF that are so difficult to
> understand, there is also a glibc-specific aspect here: The FSF is
> ignoring large-scale LGPL infringement that comes with incorrect use of
> container technology.  (At the very least, publishing a container image
> with glibc in it requires certain legal notices according to the LGPL
> terms, and all binaries linked against glibc must be re-linkable against
> a changed glibc.)  This has reached such a degree that distributors of
> container images might legally assume that the FSF has waived any and
> all LGPL requirements, which the FSF can do as the copyright owner.

I don't know about this specific case, but it sounds like something to
raise up with the FSF, and urgently.

> If true, only an influx of additional copyright owners for glibc can
> preserve the (limited) copyleft nature of glibc.

How will it do that?  If you have 100 or 500 or 1000 copyright owners,
how would glibc do better in case of such infringements?

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

[Florian Weimer]

* Eli Zaretskii:

>> From: Florian Weimer <fweimer@redhat.com>
>> Cc: Siddhesh Poyarekar <siddhesh@gotplt.org>,  Eli Zaretskii <eliz@gnu.org>
>> Date: Fri, 25 Jun 2021 09:24:51 +0200
>> 
>> * Eli Zaretskii via Libc-alpha:
>> 
>> > I'm showing text from the assignment agreement that IMO clearly says
>> > the developer retains all the rights.
>> 
>> No, the developer gives up copyright ownership.
>
> I don't understand what that means, sorry.  The text says I can do
> anything and everything I want with the code, except interfering with
> the FSF's use of that code.  So what exactly did I give up?

Ownership, that is, you don't control anymore who gets to use the code
and under what terms.

>> This has real legal consequences, and it is quite different from a
>> broad-ranging license to use the contributions.  If the FSF wanted
>> the latter, it could ask for precisely that, but instead it asks for
>> full ownership.
>
> I looked up all the instances of "owner" and "ownership" in the CLA
> text, and couldn't find where they ask for "full ownership".  What did
> I miss?

I have a personal FSF copyright assignment that talks about “rights of
the copyright owner” and “the right to enforce the copyright”.  The FSF
probably uses different assignment contracts over time and for different
components.

(Another advantage of the DCO: the terms are totally transparent.)

Thanks,
Florian

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

[Eli Zaretskii]

> From: Florian Weimer <fweimer@redhat.com>
> Cc: libc-alpha@sourceware.org,  siddhesh@gotplt.org
> Date: Fri, 25 Jun 2021 10:23:06 +0200
> 
> >> No, the developer gives up copyright ownership.
> >
> > I don't understand what that means, sorry.  The text says I can do
> > anything and everything I want with the code, except interfering with
> > the FSF's use of that code.  So what exactly did I give up?
> 
> Ownership, that is, you don't control anymore who gets to use the code
> and under what terms.

The code I contributed to the project, I don't control, indeed.  But I
can distribute my code separately under any conditions I like.  I
don't see how this constitutes giving up ownership.

IOW, there are two copies of my code: the copyright for what I
contributed to the project belongs to the FSF, but the copyright for
the code I distribute independently belongs to me.

> >> This has real legal consequences, and it is quite different from a
> >> broad-ranging license to use the contributions.  If the FSF wanted
> >> the latter, it could ask for precisely that, but instead it asks for
> >> full ownership.
> >
> > I looked up all the instances of "owner" and "ownership" in the CLA
> > text, and couldn't find where they ask for "full ownership".  What did
> > I miss?
> 
> I have a personal FSF copyright assignment that talks about “rights of
> the copyright owner” and “the right to enforce the copyright”.

  (e) FSF has all the rights of a copyright owner in the assigned
      copyrights, subject to the license grantback to developer stated
      above, including the right to enforce the copyright in aid of
      the free software purposes of this agreement, the right to use,
      license and distribute the Works, and the right to make works
      based on the Works and use, license and distribute them, with
      the Program or as standalone modules, all as made or acquired by
      Developer or in modified form. FSF may charge a fee of its
      choosing for the service of distribution.

But:

  (c) Developer is not obliged to defend FSF against any spurious
      claim of adverse copyright ownership, but will cooperate with
      FSF in defending against any such claim and will indemnify FSF
      for all losses if the claim is not spurious, i.e. if the adverse
      claimant is a true copyright holder and FSF is thereby damaged,
      including but not limited to the amount of all adverse damage
      judgments and costs of litigation.

This says nothing to the effect that the developers cannot by
themselves try to enforce the copyright, should they wish to do so.

So I still don't see the giving up of ownership or control on who uses
the code and how.  The developer gives the FSF the right to distribute
the changes together with the program they changed, and make
derivative software based on that, as the FSF sees fit, that's all.
Which is all consistent with fair use of free software, AFAICT.

> (Another advantage of the DCO: the terms are totally transparent.)

"Transparent" in what sense?

Re: 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 07:53:49 +0530
> 
> 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.

Oh, and talking about dishonest contributors is not useful.  I'm
talking about the honest ones.  If someone wants to lie about the
legal status of the code, and they succeed in answering all the
questions the FSF copyright clerk asks them, there's nothing you could
do about it, no matter what kind of legal document you request.  But
that doesn't mean legal documents are useless, because most
contributors are honest.

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

[Craig Topham]

>>>/From: Florian Weimer <fweimer@redhat.com <mailto:fweimer@redhat.com>> />>>/Cc: Siddhesh Poyarekar <siddhesh@gotplt.org
<mailto:siddhesh@gotplt.org>>, Eli Zaretskii <eliz@gnu.org
<mailto:eliz@gnu.org>> />>>/Date: Fri, 25 Jun 2021 09:24:51 +0200 />>>//>>>/* Eli Zaretskii via Libc-alpha: />>>//>>>/> I'm showing text from the assignment agreement that IMO clearly says />>>/> the developer retains all the rights. />>>//>>>/No, the developer gives up copyright ownership. />>//>>/I don't understand what that means, sorry. The text says I can do />>/anything and everything I want with the code, except interfering with />>/the FSF's use of that code. So what exactly did I give up? /
> Ownership, that is, you don't control anymore who gets to use the code
> and under what terms.

The grant back in section 1 (d) of the FSF's copyright assignment
gives control to the developer who can then decide who gets to use the
code and under what terms, but the developer cannot limit how the FSF
distributes and uses the code, which is under a free license, most
likely the GPLv3 or later.

~Craig

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

[Szabolcs Nagy]

The 07/02/2021 15:23, Craig Topham via Libc-alpha wrote:
> >>>/From: Florian Weimer <fweimer@redhat.com <mailto:fweimer@redhat.com>> />>>/Cc: Siddhesh Poyarekar <siddhesh@gotplt.org
> <mailto:siddhesh@gotplt.org>>, Eli Zaretskii <eliz@gnu.org
> <mailto:eliz@gnu.org>> />>>/Date: Fri, 25 Jun 2021 09:24:51 +0200 />>>//>>>/* Eli Zaretskii via Libc-alpha: />>>//>>>/> I'm showing text from the assignment agreement that IMO clearly says />>>/> the developer retains all the rights. />>>//>>>/No, the developer gives up copyright ownership. />>//>>/I don't understand what that means, sorry. The text says I can do />>/anything and everything I want with the code, except interfering with />>/the FSF's use of that code. So what exactly did I give up? /
> > Ownership, that is, you don't control anymore who gets to use the code
> > and under what terms.
> 
> The grant back in section 1 (d) of the FSF's copyright assignment
> gives control to the developer who can then decide who gets to use the
> code and under what terms, but the developer cannot limit how the FSF
> distributes and uses the code, which is under a free license, most
> likely the GPLv3 or later.

a copyright assignment cannot possibly "give control"
to the developer: there can be multiple projects that
require assignment (or even just a statement from the
owner) and the developer cannot contribte the same
code to those (you can only assign ownership once).

giving control over the license terms does not matter
when there are many projects that require ownership
or statement from the owner (gnu projects are just one
example). not being an owner creates real barriers for
a developer. and the only way out is to avoid any
projects that require assignment.

(this came up multiple times in the past with respect
to string and math code that many projects have their
separate copy of and fsf assignment was always in the
way to do the right thing: share the code as widely
as possible)

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

[Eli Zaretskii]

> Date: Mon, 5 Jul 2021 15:59:03 +0100
> From: Szabolcs Nagy <szabolcs.nagy@arm.com>
> Cc: libc-alpha@sourceware.org, fweimer@redhat.com, siddhesh@gotplt.org,
> 	eliz@gnu.org
> 
> > The grant back in section 1 (d) of the FSF's copyright assignment
> > gives control to the developer who can then decide who gets to use the
> > code and under what terms, but the developer cannot limit how the FSF
> > distributes and uses the code, which is under a free license, most
> > likely the GPLv3 or later.
> 
> a copyright assignment cannot possibly "give control"
> to the developer: there can be multiple projects that
> require assignment (or even just a statement from the
> owner) and the developer cannot contribte the same
> code to those (you can only assign ownership once).

AFAIK, that's not true: the developer _can_ assign the copyright to
more than one project.

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

[Paul Eggert]

On 7/5/21 9:48 AM, Eli Zaretskii via Libc-alpha wrote:
> the developer_can_  assign the copyright to
> more than one project.

Yes, in the US one can transfer a copyright owner's rights on either a 
exclusive or an nonexclusive basis. Nonexclusive licenses can be to more 
than one recipient; exclusive ones cannot. Exclusive transfers must be 
documented by a written agreement; nonexclusive transfers need not be.

The GCC DCO form <https://www.gnu.org/software//gcc/dco.html> does not 
make it clear whether it's an exclusive or nonexclusive transfer and 
does not seem to involve a legal assignment, so these transfers must be 
nonexclusive licenses. If Glibc uses a similar form, its DCO'ed 
contributions would also be nonexclusive.

I'm a bit surprised that this important legal detail isn't stated on the 
form. But perhaps the lawyers who drew it up didn't want to scare off 
non-lawyers.

Seeking input from developers: glibc copyright assignment policy.

[Carlos O'Donell]

Community,

glibc was created as part of the GNU Project but has grown to operate as
an autonomous project. As part of the GNU Toolchain the glibc stewards
support the gcc project policy changes presented here:
https://gcc.gnu.org/pipermail/gcc/2021-June/236182.html

The glibc stewards are seeking input from developers to decide if the project
should relax the requirement to assign copyright for all changes to the
Free Software Foundation as follows:

Contributors who have an FSF Copyright Assignment wouldn't need to
change anything.  Contributors who wish to utilize the Developer Certificate
of Origin[1] would add a Signed-off-by message to their commit messages.

The changes to accept patches with or without FSF copyright assignment
would be effective on August 2nd, and would apply to all open branches.

The glibc stewards, like the GCC SC, continue to affirm the principles of
Free Software, and that will never change.

glibc will continue to be developed, distributed, and licensed under the
GNU Lesser General Public License v2.1 or any later version as
published by the Free Software Foundation.

Input on this issue is accepted until July 1st 2021.

Signed,
Ryan Arnold
Paul Eggert
Jakub Jelinek
Maxim Kuvyrkov
Joseph Myers
Carlos O'Donell

[1] https://developercertificate.org/

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

[Rich Felker]

On Mon, Jun 14, 2021 at 02:52:03PM -0400, Carlos O'Donell via Libc-alpha wrote:
> Community,
> 
> glibc was created as part of the GNU Project but has grown to operate as
> an autonomous project. As part of the GNU Toolchain the glibc stewards
> support the gcc project policy changes presented here:
> https://gcc.gnu.org/pipermail/gcc/2021-June/236182.html
> 
> The glibc stewards are seeking input from developers to decide if the project
> should relax the requirement to assign copyright for all changes to the
> Free Software Foundation as follows:
> 
> Contributors who have an FSF Copyright Assignment wouldn't need to
> change anything.  Contributors who wish to utilize the Developer Certificate
> of Origin[1] would add a Signed-off-by message to their commit messages.
> 
> The changes to accept patches with or without FSF copyright assignment
> would be effective on August 2nd, and would apply to all open branches.
> 
> The glibc stewards, like the GCC SC, continue to affirm the principles of
> Free Software, and that will never change.
> 
> glibc will continue to be developed, distributed, and licensed under the
> GNU Lesser General Public License v2.1 or any later version as
> published by the Free Software Foundation.
> 
> Input on this issue is accepted until July 1st 2021.

I am very much in favor of removing the assignment requirement. I do
not, and have never, had an assignment in place (it's a running joke
that my patch contributions have been all-minus-signs) but given
recent behavior by the FSF board, I am completely unwilling to assign
copyright to them in the future, so not making this change may affect
my ability to contribute.

Rich

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

[Khem Raj]

On Mon, Jun 14, 2021 at 12:08 PM Rich Felker <dalias@libc.org> wrote:
>
> On Mon, Jun 14, 2021 at 02:52:03PM -0400, Carlos O'Donell via Libc-alpha wrote:
> > Community,
> >
> > glibc was created as part of the GNU Project but has grown to operate as
> > an autonomous project. As part of the GNU Toolchain the glibc stewards
> > support the gcc project policy changes presented here:
> > https://gcc.gnu.org/pipermail/gcc/2021-June/236182.html
> >
> > The glibc stewards are seeking input from developers to decide if the project
> > should relax the requirement to assign copyright for all changes to the
> > Free Software Foundation as follows:
> >
> > Contributors who have an FSF Copyright Assignment wouldn't need to
> > change anything.  Contributors who wish to utilize the Developer Certificate
> > of Origin[1] would add a Signed-off-by message to their commit messages.
> >
> > The changes to accept patches with or without FSF copyright assignment
> > would be effective on August 2nd, and would apply to all open branches.
> >
> > The glibc stewards, like the GCC SC, continue to affirm the principles of
> > Free Software, and that will never change.
> >
> > glibc will continue to be developed, distributed, and licensed under the
> > GNU Lesser General Public License v2.1 or any later version as
> > published by the Free Software Foundation.
> >
> > Input on this issue is accepted until July 1st 2021.
>
> I am very much in favor of removing the assignment requirement.

+1.  adding an option to accept patches with DCO would greatly
simplify this for new/occasional
contributors

> not, and have never, had an assignment in place (it's a running joke
> that my patch contributions have been all-minus-signs) but given
> recent behavior by the FSF board, I am completely unwilling to assign
> copyright to them in the future, so not making this change may affect
> my ability to contribute.

+1

>
> Rich

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

[Florian Weimer]

* Carlos O'Donell via Libc-alpha:

> The glibc stewards are seeking input from developers to decide if the project
> should relax the requirement to assign copyright for all changes to the
> Free Software Foundation as follows:
>
> Contributors who have an FSF Copyright Assignment wouldn't need to
> change anything.  Contributors who wish to utilize the Developer Certificate
> of Origin[1] would add a Signed-off-by message to their commit messages.
>
> The changes to accept patches with or without FSF copyright assignment
> would be effective on August 2nd, and would apply to all open branches.
>
> The glibc stewards, like the GCC SC, continue to affirm the principles of
> Free Software, and that will never change.
>
> glibc will continue to be developed, distributed, and licensed under the
> GNU Lesser General Public License v2.1 or any later version as
> published by the Free Software Foundation.

Given that we already have hundreds of commits with Signed-off-by:, and
glibc has accepted contributions written for glibc under different,
LGLPv2-compatible licenses without copyright assignment in the past,
this is a welcome clarification.

Will gnulib adopt a similar policy?

Thanks,
Florian

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

[Matt Turner]

On Mon, Jun 14, 2021 at 1:06 PM Florian Weimer via Libc-alpha
<libc-alpha@sourceware.org> wrote:
> Given that we already have hundreds of commits with Signed-off-by:, and
> glibc has accepted contributions written for glibc under different,
> LGLPv2-compatible licenses without copyright assignment in the past,
> this is a welcome clarification.

FWIW, this is why I asked and convinced some Mesa developers to stop
appending S-o-b tags to their commits: without an assigned meaning,
all it does is complicate matters when a project does adopt a DCO and
indicates its acceptance through S-o-b tags.

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

[Carlos O'Donell]

On 6/14/21 4:22 PM, Matt Turner via Libc-alpha wrote:
> On Mon, Jun 14, 2021 at 1:06 PM Florian Weimer via Libc-alpha
> <libc-alpha@sourceware.org> wrote:
>> Given that we already have hundreds of commits with Signed-off-by:, and
>> glibc has accepted contributions written for glibc under different,
>> LGLPv2-compatible licenses without copyright assignment in the past,
>> this is a welcome clarification.
> 
> FWIW, this is why I asked and convinced some Mesa developers to stop
> appending S-o-b tags to their commits: without an assigned meaning,
> all it does is complicate matters when a project does adopt a DCO and
> indicates its acceptance through S-o-b tags.

Thank you for that feedback.

I agree that Signed-off-by: needs to have a defined meaning for there
to be a benefit created for the project.

-- 
Cheers,
Carlos.

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

[Paul Eggert]

On 6/14/21 1:05 PM, Florian Weimer via Libc-alpha wrote:
> Given that we already have hundreds of commits with Signed-off-by:, and
> glibc has accepted contributions written for glibc under different,
> LGLPv2-compatible licenses without copyright assignment in the past,
> this is a welcome clarification.
> 
> Will gnulib adopt a similar policy?

I would expect so. In many cases we simply copy from glibc, so we're 
using glibc's policy there. For non-glibc files, Gnulib could stick with 
the current policy, or move to glibc's policy.

Today I raised this issue on bug-gnulib to solicit Gnulib developers' 
opinions <https://lists.gnu.org/r/bug-gnulib/2021-06/msg00079.html>.

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

[Matt Turner]

On Mon, Jun 14, 2021 at 11:53 AM Carlos O'Donell via Libc-alpha
<libc-alpha@sourceware.org> wrote:
>
> Community,
>
> glibc was created as part of the GNU Project but has grown to operate as
> an autonomous project. As part of the GNU Toolchain the glibc stewards
> support the gcc project policy changes presented here:
> https://gcc.gnu.org/pipermail/gcc/2021-June/236182.html
>
> The glibc stewards are seeking input from developers to decide if the project
> should relax the requirement to assign copyright for all changes to the
> Free Software Foundation as follows:
>
> Contributors who have an FSF Copyright Assignment wouldn't need to
> change anything.  Contributors who wish to utilize the Developer Certificate
> of Origin[1] would add a Signed-off-by message to their commit messages.
>
> The changes to accept patches with or without FSF copyright assignment
> would be effective on August 2nd, and would apply to all open branches.

Yes, please!

To give a concrete example of what a barrier this can be to contributors:

When I was in graduate school and contracting for OLPC, I wanted to
contribute a fix to GCC [1]. I was asked to complete the copyright
assignment paperwork and disclosed that I was a student in university.
That necessitated the FSF paperwork being approved by my university...

Research universities often have technology-transfer rules, designed
around handling inventions created by professors and research
assistants. Despite not doing research for the university, not working
on GCC for the university, not doing the work with anyone from the
university, and not doing the work with any property from the
university, the university required me to fill out paperwork
describing the "invention" and provide information on how they might
"market it".

A process which began in October finally concluded in April, the month
before I graduated. Not coincidentally, someone in the tech-transfer
office asked me if I could simply wait until after I graduated to
contribute...

I can imagine most people would simply not contribute if they knew
they'd have to go through this (or neglect to mention to the FSF that
they're a university student, as I would do if I had known).

None of this is the fault of the copyright assignment policy per se,
but it does demonstrate how it's not as simple as signing a piece of
paper.

[1] I believe it was
https://patchwork.ozlabs.org/project/gcc/patch/CAEdQ38ECXJahf8sp8b7Yq5NgOQBh9MQ7s3LxfSmZJhJva-UfDg@mail.gmail.com/

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

[Adhemerval Zanella]

On 14/06/2021 15:52, Carlos O'Donell via Libc-alpha wrote:
> Community,
> 
> glibc was created as part of the GNU Project but has grown to operate as
> an autonomous project. As part of the GNU Toolchain the glibc stewards
> support the gcc project policy changes presented here:
> https://gcc.gnu.org/pipermail/gcc/2021-June/236182.html
> 
> The glibc stewards are seeking input from developers to decide if the project
> should relax the requirement to assign copyright for all changes to the
> Free Software Foundation as follows:
> 
> Contributors who have an FSF Copyright Assignment wouldn't need to
> change anything.  Contributors who wish to utilize the Developer Certificate
> of Origin[1] would add a Signed-off-by message to their commit messages.
> 
> The changes to accept patches with or without FSF copyright assignment
> would be effective on August 2nd, and would apply to all open branches.
> 
> The glibc stewards, like the GCC SC, continue to affirm the principles of
> Free Software, and that will never change.
> 
> glibc will continue to be developed, distributed, and licensed under the
> GNU Lesser General Public License v2.1 or any later version as
> published by the Free Software Foundation.
> 
> Input on this issue is accepted until July 1st 2021.

From the gcc maillist thread [1], it seemed that the vast majority if not
all gcc developers were in favor of the change. I also agree this is the
way forward to help improve contributions and the project engagement. 

[1] https://gcc.gnu.org/pipermail/gcc/2021-June/236182.html

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

[Siddhesh Poyarekar]

On 6/15/21 12:22 AM, Carlos O'Donell via Libc-alpha wrote:
> Community,
> 
> glibc was created as part of the GNU Project but has grown to operate as
> an autonomous project. As part of the GNU Toolchain the glibc stewards
> support the gcc project policy changes presented here:
> https://gcc.gnu.org/pipermail/gcc/2021-June/236182.html
> 
> The glibc stewards are seeking input from developers to decide if the project
> should relax the requirement to assign copyright for all changes to the
> Free Software Foundation as follows:
> 
> Contributors who have an FSF Copyright Assignment wouldn't need to
> change anything.  Contributors who wish to utilize the Developer Certificate
> of Origin[1] would add a Signed-off-by message to their commit messages.
> 
> The changes to accept patches with or without FSF copyright assignment
> would be effective on August 2nd, and would apply to all open branches.
> 
> The glibc stewards, like the GCC SC, continue to affirm the principles of
> Free Software, and that will never change.
> 
> glibc will continue to be developed, distributed, and licensed under the
> GNU Lesser General Public License v2.1 or any later version as
> published by the Free Software Foundation.
> 
> Input on this issue is accepted until July 1st 2021.

As someone who has nagged about this at practically every Cauldron I've 
attended, I think this is a positive change and I fully endorse it.  The 
copyright assignment step has been a pretty significant hurdle for me in 
the past when I've tried to get more students in India involved in the 
GNU toolchain.

Siddhesh

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

[DJ Delorie]

"Carlos O'Donell via Libc-alpha" <libc-alpha@sourceware.org> writes:
> Contributors who have an FSF Copyright Assignment wouldn't need to
> change anything.  Contributors who wish to utilize the Developer Certificate
> of Origin[1] would add a Signed-off-by message to their commit messages.

I'm for this change, but it's my belief that the DCO will be treated
like a EULA - don't read it, just accept it.  I will consider every
"Signed-off-by:" as a "I-don't-know-if-I-own-this:" admission.  "I don't
need to check with legal, I just need to put this line in my email and
everything is OK."

However, the FSF assignment is the biggest roadblock to new
contributors, and I think that's a bigger potential problem than the
potential DCO problems.

> glibc will continue to be developed, distributed, and licensed under
> the GNU Lesser General Public License v2.1 or any later version as
> published by the Free Software Foundation.

This paragraph was worded poorly.  We will not be developing under any
later version, ever.  We will distribute under terms that allow using
later versions' terms.  The DCO means we will never change the version
of GPL we use, it's important to not blur that point.

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

[Paul Eggert]

On 6/14/21 8:18 PM, DJ Delorie via Libc-alpha wrote:
> The DCO means we will never change the version
> of GPL we use

If the DCO really means that then it could be trouble, as copyright law 
mutates and the LGPL clause that lets you redistribute under later 
versions is an important escape hatch to deal with future changes to 
copyright law.

But I don't understand why the DCO really means that; could you explain?

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

[DJ Delorie]

Paul Eggert <eggert@cs.ucla.edu> writes:
> On 6/14/21 8:18 PM, DJ Delorie via Libc-alpha wrote:
>> The DCO means we will never change the version
>> of GPL we use
>
> If the DCO really means that then it could be trouble, as copyright law 
> mutates and the LGPL clause that lets you redistribute under later 
> versions is an important escape hatch to deal with future changes to 
> copyright law.
>
> But I don't understand why the DCO really means that; could you explain?

If N people collectively own copyright, then all N need to agree in
order to change the licensing terms.  The Linux kernel is stuck at GPL2
for this reason; they effectively can't get all the copyright owners to
agree to change it.

DCO means that N > 1 for glibc.  The higher N is, the harder it is to
get agreements to change.

Note that the 'or later versions' clause does NOT let anyone arbitrarily
change the license!  If $person takes a copy of glibc and distributes it
to $person2 under the terms of GPLv4, then $person2 still has the "GPLv3
or later" option; they obtain their license from the owners, not from
the intermediates, so how the intermediates choose to redistribute is -
from a license point of view - irrelevent.

So once our DCO count is high enough, glibc is stuck with "GPLv3 or
later".  Folks (including us) will always have the option of following a
later GPL, but they will also always have the option of following GPLv3.

Of course, the usual IANAL.

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

[Paul Eggert]

On 6/15/21 11:43 AM, DJ Delorie wrote:

> The Linux kernel is stuck at GPL2
> for this reason; they effectively can't get all the copyright owners to
> agree to change it.

That's because the Linux code is distributed under its own terms, which 
is mostly LGPL2-only. That is, they've stuck at LGPL2 on purpose.

In contrast, the Glibc library code is explicitly LGPL2.1+ (with 
emphasis on the "+"). DCO'd contributions to GLibc would be under 
Glibc's terms, not Linux's. Since Glibc's terms explicitly allow it to 
be redistributed under later versions of the LGPL, a future Glibc 
release could use LGPL4 (should a version 4 ever come out).

You're right that if Glibc switches to a future LGPL4 then Glibc's DCO'd 
parts (if unmodified) could still be redistributed separately under 
LGPLv2.1, just as any other part of glibc (if unmodified) would continue 
to be redistributable under LGPLv2.1. However, the new glibc library 
code as a whole could simply move to LGPL4 without any licensing issues 
presented by the DCO components.

Currently this issue is no big deal, because for various reasons Glibc 
library code is stuck on LGPL2.1 even though LGPL3.0 came out in 2007. 
But if copyright law changes and an LGPL 4 becomes necessary, the 
distinction could become important.

> Of course, the usual IANAL.

Oh likewise, likewise.

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

[DJ Delorie]

Paul Eggert <eggert@cs.ucla.edu> writes:
> In contrast, the Glibc library code is explicitly LGPL2.1+ (with 
> emphasis on the "+"). DCO'd contributions to GLibc would be under 
> Glibc's terms, not Linux's. Since Glibc's terms explicitly allow it to 
> be redistributed under later versions of the LGPL,

So far so good.

> a future Glibc release could use LGPL4 (should a version 4 ever come
> out).

Sorta.  A future glibc could distribute under the terms of LGPL4+, but a
future glibc could NOT change the license to "LGPL4+".  I.e. if LGPL2.1
had a problem, we could not fix the problem by preventing LGPL2.1 from
being used.  *We* could use LGPL4, but we can't take away someone else's
right to use LGPL2.1.  Only the copyright owner(s) can do that.

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

[Paul Eggert]

On 6/15/21 12:12 PM, DJ Delorie wrote:
> A future glibc could distribute under the terms of LGPL4+, but a
> future glibc could NOT change the license to "LGPL4+".

So, are you saying that in string/strcpy.c we could not change the "2.1" 
to 3 in the following comment:

    The GNU C Library is free software; you can redistribute it and/or
    modify it under the terms of the GNU Lesser General Public
    License as published by the Free Software Foundation; either
    version 2.1 of the License, or (at your option) any later version.

and redistribute the result, assuming strcpy.c has some DCO'ed code? 
We've routinely been doing such replacements for years in other Gnu 
code. Gnulib even automates the practice.

If true, it's a significant argument against going with DCO'ed code. 
Certainly we couldn't accept DCO'ed material in any Glibc code shared 
with Gnulib, as Gnulib code is shared among many GNU projects that don't 
do DCO and do such rewriting. And even if we ignore Gnulib, this could 
be a real problem if copyright law were to change in a way that 
adversely affects free-software principles, so that we'd really need an 
LGPL 4.

Have the Red Hat lawyers looked into this issue specifically?

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

[DJ Delorie]

Paul Eggert <eggert@cs.ucla.edu> writes:
> On 6/15/21 12:12 PM, DJ Delorie wrote:
>> A future glibc could distribute under the terms of LGPL4+, but a
>> future glibc could NOT change the license to "LGPL4+".
>
> So, are you saying that in string/strcpy.c we could not change the "2.1" 
> to 3 in the following comment:

Only of all the copyright owners of that file agreed.  That is, the FSF
plus any DCO'd patches' owners.

> If true, it's a significant argument against going with DCO'ed code. 

Yes, that is a key thing here.  Whether that's a pro or a con is up to
you.

pro: A future EvilFSF can't make the code non-free.

con: Bugs in GPL can't be fixed.

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

[Carlos O'Donell]

On 6/15/21 3:35 PM, Paul Eggert wrote:
> On 6/15/21 12:12 PM, DJ Delorie wrote:
>> A future glibc could distribute under the terms of LGPL4+, but a 
>> future glibc could NOT change the license to "LGPL4+".
> 
> So, are you saying that in string/strcpy.c we could not change the
> "2.1" to 3 in the following comment:

This changes the license of the code.
 
> The GNU C Library is free software; you can redistribute it and/or 
> modify it under the terms of the GNU Lesser General Public License as
> published by the Free Software Foundation; either version 2.1 of the
> License, or (at your option) any later version.
> 
> and redistribute the result, assuming strcpy.c has some DCO'ed code?
> We've routinely been doing such replacements for years in other Gnu
> code. Gnulib even automates the practice.

You should contact legal counsel to determine if you have the right
to relicense that code.

> If true, it's a significant argument against going with DCO'ed code.

Why is it a significant argument against DCO?

Yes, does make it more difficult to relicense the project (it is not
impossible), other than to a later version of the GPL. We are a mature 
collection of projects and our users and developers depend on the
project to retain the existing license for long term planning. Users
and developers contribute to our projects because of our values and
principles and those are tied to the license that we are using.

Telling our users and developers that we will never change the license
has value.

> Certainly we couldn't accept DCO'ed material in any Glibc code shared
> with Gnulib, as Gnulib code is shared among many GNU projects that
> don't do DCO and do such rewriting. And even if we ignore Gnulib,
> this could be a real problem if copyright law were to change in a way
> that adversely affects free-software principles, so that we'd really
> need an LGPL 4.

Can you quantify this risk of not being able to move to LGPLv4?

Can you quantify the risk of using DCO?

What license would we change to?

Does the LGPLv4 exist today?

What do our users expect?

The problem is that risk quantification is difficult and neither side
has a clear advantage against all costs and benefits.

The clearest advantage to DCO is the future growth and vibrancy of the
GNU Toolchain. The GNU Toolchain deserves the brightest future we can
provide.

In practice glibc contains a fair bit of code unassigned to the FSF for
which the license cannot be easily changed without legal discussions
(Intel, IBM, Sun Microsystems, SGI, Oracle, Carnegie Mellon University,
DEC, ISC, University of California, University of Cambridge, ORNL,
Unicode Consortium, and various authors). And some companies no longer
exist.

There are approximately 704 files that have copyright owners other than
the FSF, and if the FSF does have copyright ownership by other contractual
means then that isn't clear and subject to complex legal discussions for
relicensing.

The reality of the GNU Toolchain copyright ownership is different
from expectation.

The DCO is in keeping with the reality of the GNU Toolchain and opens
up opportunities for further contributions.

> Have the Red Hat lawyers looked into this issue specifically?

This is a known issue with DCO.

If there is a specific question you have then we can start a thread
to discuss the issue.

-- 
Cheers,
Carlos.

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

[Carlos O'Donell]

On 6/15/21 3:35 PM, Paul Eggert wrote:
> If true, it's a significant argument against going with DCO'ed code.
> Certainly we couldn't accept DCO'ed material in any Glibc code shared
> with Gnulib, as Gnulib code is shared among many GNU projects that
> don't do DCO and do such rewriting.

gnulib already accepts such code.

gnulib has been including non-FSF copyrighted material in various 
modules (that include the files below) for a long time.

gnulib could add markup to the modules to indicate if they contain
non-FSF copyrighted material, and then allow the including projects
to decide if this is acceptable to them or not?

The following files in gnulib are not copyright the FSF:

lib/acosl.c:
Copyright (C) 1993 by Sun Microsystems, Inc. All rights reserved.

lib/asinl.c:
Copyright (C) 1993 by Sun Microsystems, Inc. All rights reserved.

lib/cosl.c:
Copyright (C) 1993 by Sun Microsystems, Inc. All rights reserved.

lib/sinl.c:
Copyright (C) 1993 by Sun Microsystems, Inc. All rights reserved.

lib/tanl.c:
Copyright (C) 1993 by Sun Microsystems, Inc. All rights reserved.

lib/trigl.c:
Copyright (C) 1993 by Sun Microsystems, Inc. All rights reserved.

lib/atanl.c:
Copyright 2001 by Stephen L. Moshier <moshier@na-net.ornl.gov>

lib/cbrtl.c:
Copyright 1984, 1991 by Stephen L. Moshier

lib/logl.c:
Copyright 2001 by Stephen L. Moshier <moshier@na-net.ornl.gov>

lib/filevercmp.c:
lib/filevercmp.h:
Copyright (C) 1995 Ian Jackson <iwj10@cus.cam.ac.uk>
Copyright (C) 2001 Anthony Towns <aj@azure.humbug.org.au>

lib/fts.c:
Copyright (c) 1990, 1993, 1994 The Regents of the University of California.  All rights reserved.

lib/fts_.h:
Copyright (c) 1989, 1993 The Regents of the University of California.  All rights reserved.

lib/inet_ntop.c:
Copyright (c) 1996-1999 by Internet Software Consortium.

lib/inet_pton.c:
Copyright (c) 1996,1999 by Internet Software Consortium.

lib/random.c:
lib/random_r.c:
Copyright (C) 1983 Regents of the University of California. All rights reserved.

lib/sigsegv.c:
Copyright (C) 2018  Nylon Chen <nylon7@andestech.com>

lib/stackvma.c:
lib/stackvma.h:
Copyright (C) 2003-2006  Paolo Bonzini <bonzini@gnu.org>

-- 
Cheers,
Carlos.

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

[Paul Eggert]

On 7/2/21 3:33 PM, Carlos O'Donell wrote:

> gnulib has been including non-FSF copyrighted material in various
> modules (that include the files below) for a long time.

If gnulib-tool modifies any of those non-FSF copyright notices, then 
that's a bug that should be fixed. It doesn't modify the first one, so 
we should be OK there. (I didn't check the others.)

This raises another issue. What will be the glibc policy about putting 
copyright notices on files containing DCOed material? Will there be a 
separate copyright notice for each contributor? Linux doesn't do that - 
which is too sloppy for glibc, surely. I don't know what GCC plans to do.

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

[Paul Eggert]

On 7/2/21 6:59 PM, Paul Eggert wrote:

> If gnulib-tool modifies any of those non-FSF copyright notices, then 
> that's a bug that should be fixed.

I've been reminded that gnulib-tool no longer modifies copyright 
notices, so there's no bug here.

> What will be the glibc policy about putting 
> copyright notices on files containing DCOed material? Will there be a 
> separate copyright notice for each contributor? Linux doesn't do that - 
> which is too sloppy for glibc, surely. I don't know what GCC plans to do.

Following up on this, I propose that if DCO'ed contributions are 
accepted for a file, the file should contain a proper copyright notice 
listing the authors and the range of years that each contributed. E.g., 
the start of the file would look like this:

   /* Word-wrapping and line-truncating streams.
      Copyright (C) 1997-2022 Free Software Foundation, Inc.
      Copyright (C) 2021-2022 Alejandro Davis.
      Copyright (C) 2022 Sharon Carter, Debra Lindsey.
      This file is part of the GNU C Library.

      The GNU C Library is free software; you can redistribute it ...

This issue shouldn't arise for Glibc files shared with Gnulib, as 
they'll still follow the current policy.

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

[Florian Weimer]

* Paul Eggert:

> Following up on this, I propose that if DCO'ed contributions are
> accepted for a file, the file should contain a proper copyright notice 
> listing the authors and the range of years that each
> contributed. E.g., the start of the file would look like this:
>
>   /* Word-wrapping and line-truncating streams.
>      Copyright (C) 1997-2022 Free Software Foundation, Inc.
>      Copyright (C) 2021-2022 Alejandro Davis.
>      Copyright (C) 2022 Sharon Carter, Debra Lindsey.
>      This file is part of the GNU C Library.
>
>      The GNU C Library is free software; you can redistribute it ...
>
> This issue shouldn't arise for Glibc files shared with Gnulib, as
> they'll still follow the current policy.

I would prefer something along the lines “Copyright The glibc
Contributors”.  No year or year range, no individual names.  Listing
years is apparently not legally required, and naming individual authors
is also optional.  See:

  Copyright Notices in Open Source Software Projects 
  <https://www.linuxfoundation.org/en/blog/copyright-notices-in-open-source-software-projects/>

Today, we have some trouble removing “Contributed by” lines in cases
where they may be no longer applicable.  I don't think we should create
more problems like that.

Thanks,
Florian

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

[Paul Eggert]

On 7/4/21 4:55 AM, Florian Weimer wrote:
> I would prefer something along the lines “Copyright The glibc
> Contributors”.  No year or year range, no individual names.  Listing
> years is apparently not legally required

That's an oversimplification of copyright law. In the US although no 
copyright notice is legally *required* to hold a copyright, there are 
legal *benefits* to having a proper copyright notice, and the FSF surely 
wants those benefits. So at the very least the FSF must be specifically 
listed in the copyright notice of any file containing material 
copyrighted by the FSF.

Whether non-FSF copyright owners want to forgo those benefits, is up to 
them. The DCO Sign-off form I've seen doesn't mention this issue, so 
it'd be safer (and more polite) to list each copyright owner.

A proper copyright notice consists of (1) "©" or "Copyright" or "Copr.", 
(2) the year(s) of first publication of the work, and (3) the name(s) of 
the copyright owner(s). For more details, please see Chapter 2200 
"Notice of Copyright" of the Compendium of US Copyright Office 
Practices, 3rd edition (2021) 
<https://www.copyright.gov/comp3/chap2200/ch2200-notice.pdf>.

To software developers this may all sound like a bunch of bureaucratic 
paperwork, but I can assure you that to a copyright attorney this stuff 
can be a big deal.

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

[Bradley M. Kuhn]

> On 7/4/21 4:55 AM, Florian Weimer wrote:
> > I would prefer something along the lines “Copyright The glibc
> > Contributors”.

IANAL, but my own experience and work with GPL enforcement and lots of
copyright issues, and information I've received from copyright attorneys over
the years have convinced me it's a big mistake to create a copyright notice
that lists as the legal entity as something that has no legal standing.  So,
unless you plan to form an organization called “the glibc Contributors”, I
advise against that notice.

What I recommend, though, if glibc is definitely going to a multi-copyright
held work, that you move copyright inventory to a single top-level file
instead of keeping it file-by-file.

In my years of examining FOSS code, I regularly find that developers,
particularly when working under the DCO, do a terrible job at keeping
file-by-file copyright inventory up-to-date.  The Linux project has
disturbingly taken to *removing* all such file-by-file copyright notices from
the source tree entirely, which is an over-correction and just as bad a
mistake in the other direction.  I just think file-by-file copyright notice
inventory has become so inaccurate in multi-copyright-held works that it
essential becomes a fiction: the copyright notice ends up being just the
first few people who worked on the file in question, and later contributors
simply forget to include an update of the copyright notices in the files.

As others have pointed out, copyright notices aren't mandatory under
copyright law to get move of the benefits.  Paul Eggert is quite correct that
there are some *minor* legal benefits in some countries to keep copyright
notices in place.  (Some folks do argue that those benefits are so strong
that it's imperative to keep copyright notices accurate on a file-by-file
basis; but I disagree with that position).  The fact is, storing copyrighted
materials in separate files on a computer is purely a technical convenience,
as copyright law doesn't generally think in terms of “what file it was in”
but rather “what is the work in question”.  (Licenses like the MPL do have
certain requirements that are file-based, but the LGPL and GPL doesn't have
these kinds of requirements.)

Thus, my usual recommendations to projects is to change the file-level notices
to something like:

/* License: LGPLv2-or-later ; copyright and license notices kept in file
** COPYRIGHT at the top level of this source tree, and available at <URL>
** if you receive this file separated from the entire source tree
*/

and then move all the file-by-file notices, with the long text from the LGPL
about the license details, plus the copyright notices, together into that
*one* file called COPYRIGHT at the top-level, and encourage contributors to
update that file if they want a copyright notice added.

Again, IANAL and TINLA.  I recommend that the Glibc developers talk to
multiple copyright attorneys about these issues before making a change, and
copyright attorneys do disagree about some of these things in my experience.
The issues you're going to face moving to a fully multi-copyright-held work
are going to be many; I urge you to sort all this out before dropping
copyright assignment.

   * * *

Finally, since I'm posting my first email here after the feedback deadline,
I'd like to inquire about what the leaders of the glibc project thought about
all the feedback received and if the plans have been made any more detailed
based on the feedback received — particularly with regard to what, if
anything, the project is going to do to figure out who the real copyright
holders are of various contributors once opt-outs of assignment begin.
--
Bradley M. Kuhn - he/him
Policy Fellow & Hacker-in-Residence at Software Freedom Conservancy
========================================================================
Become a Conservancy Supporter today: https://sfconservancy.org/supporter

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

[Christoph Hellwig]

On Sun, Jul 04, 2021 at 04:25:16PM -0700, Bradley M. Kuhn wrote:
> In my years of examining FOSS code, I regularly find that developers,
> particularly when working under the DCO, do a terrible job at keeping
> file-by-file copyright inventory up-to-date.  The Linux project has
> disturbingly taken to *removing* all such file-by-file copyright notices from
> the source tree entirely, which is an over-correction and just as bad a
> mistake in the other direction.

That is factually incorrect.  per-file copyright notices are not removed
and in fact added by many (although not all contributors).  Updates are
often rather sloppy, though.

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

[Bradley M. Kuhn]

> On Sun, Jul 04, 2021 at 04:25:16PM -0700, Bradley M. Kuhn wrote:
> > In my years of examining FOSS code, I regularly find that developers,
> > particularly when working under the DCO, do a terrible job at keeping
> > file-by-file copyright inventory up-to-date.
                                    ^^^^^^^^^^^^
Christoph Hellwig wrote:
> Updates are often rather sloppy, though.

I think we're in agreement.  It's the updates I was trying to draw attention
to.  I agree that the *initial* copyright notice upon first commit is almost
always accurately added.  I apologize if I gave the impression that I thought
the *initial* one was sloppy, too.
--
Bradley M. Kuhn - he/him
Policy Fellow & Hacker-in-Residence at Software Freedom Conservancy
========================================================================
Become a Conservancy Supporter today: https://sfconservancy.org/supporter

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

[Carlos O'Donell]

On 7/4/21 2:32 PM, Paul Eggert wrote:
> On 7/4/21 4:55 AM, Florian Weimer wrote:
>> I would prefer something along the lines “Copyright The glibc 
>> Contributors”.  No year or year range, no individual names.
>> Listing years is apparently not legally required
> 
> That's an oversimplification of copyright law. In the US although no
> copyright notice is legally *required* to hold a copyright, there are
> legal *benefits* to having a proper copyright notice, and the FSF
> surely wants those benefits. So at the very least the FSF must be
> specifically listed in the copyright notice of any file containing
> material copyrighted by the FSF.

We would absolutely continue to honour the requests of the FSF to have
their copyright notice included in the files.

Likewise under DCO we would always have a notice indicating that the
work is copyrighted.
 
> Whether non-FSF copyright owners want to forgo those benefits, is up
> to them. The DCO Sign-off form I've seen doesn't mention this issue,
> so it'd be safer (and more polite) to list each copyright owner.

It is procedurally easier to use a group name: "The GNU Toolchain Authors"
but we can honour requests to do otherwise. 

> A proper copyright notice consists of (1) "©" or "Copyright" or
> "Copr.", (2) the year(s) of first publication of the work, and (3)
> the name(s) of the copyright owner(s). For more details, please see
> Chapter 2200 "Notice of Copyright" of the Compendium of US Copyright
> Office Practices, 3rd edition (2021)
> <https://www.copyright.gov/comp3/chap2200/ch2200-notice.pdf>.

As you note, this is not required under the current established
international conventions.

-- 
Cheers,
Carlos.

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

[Paul Eggert]

On 7/4/21 10:28 PM, Carlos O'Donell wrote:
> It is procedurally easier to use a group name: "The GNU Toolchain Authors"
> but we can honour requests to do otherwise.

OK, so the start of the file with some DCOed contributions would look 
something like this?

   /* Word-wrapping and line-truncating streams.
      Copyright (C) 1997-2022 Free Software Foundation, Inc.
      Copyright (C) 2021-2022 The GNU Toolchain Authors.
      This file is part of the GNU C Library.

      The GNU C Library is free software; you can redistribute it ...

This is assuming all the DCOed contributers are OK with not being 
mentioned explicitly. This approach should work.

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

[Bradley M. Kuhn]

> On 7/4/21 10:28 PM, Carlos O'Donell wrote:
> > It is procedurally easier to use a group name: "The GNU Toolchain Authors"
> > but we can honour requests to do otherwise.

Paul Eggert wrote:
> OK, so the start of the file with some DCOed contributions would look
> something like this?
>
>   /* Word-wrapping and line-truncating streams.
>      Copyright (C) 1997-2022 Free Software Foundation, Inc.
>      Copyright (C) 2021-2022 The GNU Toolchain Authors.

Is the “GNU Toolchain Authors” a entity that legally exists?  Only a real
entity should be listed in a copyright notice.  I talked about this in
detail in my earlier post a few days ago:
   https://sourceware.org/pipermail/libc-alpha/2021-July/128467.html

Quoting the relevant part of that email:
>> it's a big mistake to create a copyright notice that lists as the legal
>> entity as something that has no legal standing.  So, unless you plan to
>> form an organization called “the glibc Contributors” [or “GNU Toolchain
>> Authors” ], I advise against that notice. [... IANAL and TINLA]

As a way to mitigate this problem and get closer to what you're trying to do,
I make the case again for moving glibc from a file-by-file copyright
inventory mechanism to a single, toplevel file one as I outlined in that
post.  Conservancy can probably spare resources to help if you'd like to do
that.

Joseph Myers wrote:
>>> with no date specified and not naming individual contributors, following
>>> the recommendations at
>>> <https://www.linuxfoundation.org/en/blog/copyright-notices-in-open-source-software-projects/>.

These recommendations, and similar ones promulgated by the LF and its SPDX
project, are considered controversial, and legal experts have not formed
consensus around them; by contrast, they are still hotly debated in FOSS
legal and licensing circles. I began proposing the toplevel file COPYRIGHT
notice mechanism as a compromise that solved many of the concerns on both
sides (desire for accurate and complete info vs. the desire for brevity in
a file-by-file situation).  I don't purport it to be a pancea, but it has
some real advantages.

There are also political and negative policy outcomes from failing to
list every copyright holder; I wrote on this issue, which to add a bit of
humor to a dry subject, I dubbed "a Gilligan's Island Copyright Notice":
   http://ebb.org/bkuhn/blog/2011/06/28/gilligans-island.html
.. the problem has not substantially changed since that blog post.
--
Bradley M. Kuhn - he/him
Policy Fellow & Hacker-in-Residence at Software Freedom Conservancy
========================================================================
Become a Conservancy Supporter today: https://sfconservancy.org/supporter

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

[Paul Eggert]

On 7/6/21 11:05 AM, Bradley M. Kuhn wrote:

> Is the “GNU Toolchain Authors” a entity that legally exists?  Only a real
> entity should be listed in a copyright notice.

Yes and no. It's OK for a copyright notice to identify owners by 
reference instead of by naming them explicitly. See section 2205.2(F) of 
the Copyright Compendium I mentioned earlier 
<https://www.copyright.gov/comp3/chap2200/ch2200-notice.pdf>. It gives 
"copyright by publisher" as an example, where the publisher must be 
obvious from the rest of the document content.

You're right, though, that without a clear statement of how one maps the 
phrase "GNU Toolchain Authors" to what the phrase refers to, the 
copyright notice would be defective. So far, we haven't come up with a 
clear statement.

Legally speaking, we don't *need* to do anything to the copyright 
notices, if the DCO contributors are OK with that. That is, we can leave 
the existing copyright notices as-is, and not mention DCOed contributors 
at all, unless their contributions contain their copyright notices. That 
would be simplest, in terms of meaning the fewest changes to existing 
source code. However, if we do this we should make the procedure clear 
to everyone concerned.

> I make the case again for moving glibc from a file-by-file copyright
> inventory mechanism to a single, toplevel file

I agree that it'd be helpful to have such a file if well-maintained, 
regardless of whether we make changes to the existing copyright notices. 
I'd welcome contributions along those lines.

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

[Florian Weimer]

* Bradley M. Kuhn:

>> On 7/6/21 11:05 AM, Bradley M. Kuhn wrote:
>> > Is the “GNU Toolchain Authors” a entity that legally exists?  Only a real
>> > entity should be listed in a copyright notice.
>
> Paul Eggert replied:
>> Yes and no. It's OK for a copyright notice to identify owners by reference
>> instead of by naming them explicitly. See section 2205.2(F) of the Copyright
>> Compendium I mentioned earlier
>> <https://www.copyright.gov/comp3/chap2200/ch2200-notice.pdf>. It gives
>> "copyright by publisher" as an example, where the publisher must be obvious
>> from the rest of the document content.
>
> Neither of us are lawyers, so it'd be best to work this through with a
> copyright attorney if we want better answers.  Relaying the conversations
> I've had with copyright attorneys on this: the publisher is of course also
> already a legal entity, too, and also there is litigation around this that
> won't show up in the Copyright Office circulars.
>
> Additionally, I and my colleagues at Conservancy have had no end of
> discussions with folks from the Copyright Office to get the “real story”
> about various things that just don't show up in the circulars as well.
>
>> I agree that it'd be helpful to have such a file if well-maintained,
>> regardless of whether we make changes to the existing copyright
>> notices. I'd welcome contributions along those lines.
>
> I'll speak to my colleagues at Conservancy to see if we can fund staff time
> to make a patchset of this nature for glibc.  I'll probably need a week or so
> to get back to you on that, but it is unlikely to be urgent.

Would this result in a accurate list of copyright holders and their
licenses, or just present the existing data from the source tree in a
new way?  The second approach does not strike me as a good idea because
the current data is likely quite inaccurate, and resubmitting it makes
it seem more authoritative than it actually is.

Thanks,
Florian

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

[Joseph Myers]

On Wed, 7 Jul 2021, Florian Weimer via Libc-alpha wrote:

> Would this result in a accurate list of copyright holders and their
> licenses, or just present the existing data from the source tree in a
> new way?  The second approach does not strike me as a good idea because
> the current data is likely quite inaccurate, and resubmitting it makes
> it seem more authoritative than it actually is.

We already have the LICENSES file listing the non-FSF copyright and 
license notices from the source files.  We could add a list of copyright 
holders covered by "The GNU Toolchain Authors" there if desired (but that 
would mean an additional patch review step for DCO patches - make sure 
that the patch contributor, employer or other copyright owner is added to 
that file if not already present and the patch is legally significant).

-- 
Joseph S. Myers
joseph@codesourcery.com

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

[Carlos O'Donell]

On 7/4/21 7:55 AM, Florian Weimer wrote:
> * Paul Eggert:
> 
>> Following up on this, I propose that if DCO'ed contributions are
>> accepted for a file, the file should contain a proper copyright notice 
>> listing the authors and the range of years that each
>> contributed. E.g., the start of the file would look like this:
>>
>>   /* Word-wrapping and line-truncating streams.
>>      Copyright (C) 1997-2022 Free Software Foundation, Inc.
>>      Copyright (C) 2021-2022 Alejandro Davis.
>>      Copyright (C) 2022 Sharon Carter, Debra Lindsey.
>>      This file is part of the GNU C Library.
>>
>>      The GNU C Library is free software; you can redistribute it ...
>>
>> This issue shouldn't arise for Glibc files shared with Gnulib, as
>> they'll still follow the current policy.
> 
> I would prefer something along the lines “Copyright The glibc
> Contributors”.  No year or year range, no individual names.  Listing
> years is apparently not legally required, and naming individual authors
> is also optional.  See:
> 
>   Copyright Notices in Open Source Software Projects 
>   <https://www.linuxfoundation.org/en/blog/copyright-notices-in-open-source-software-projects/>

The GCC SC suggestion is as follows:

"The GNU Toolchain Authors"
https://gcc.gnu.org/pipermail/gcc/2021-June/236217.html

All files that receive DCO'd material for the first time
would add the following line:

"Copyright The GNU Toolchain Authors"

in the header comment.

-- 
Cheers,
Carlos.

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

[Florian Weimer]

* Carlos O'Donell:

> On 7/4/21 7:55 AM, Florian Weimer wrote:
>> * Paul Eggert:
>> 
>>> Following up on this, I propose that if DCO'ed contributions are
>>> accepted for a file, the file should contain a proper copyright notice 
>>> listing the authors and the range of years that each
>>> contributed. E.g., the start of the file would look like this:
>>>
>>>   /* Word-wrapping and line-truncating streams.
>>>      Copyright (C) 1997-2022 Free Software Foundation, Inc.
>>>      Copyright (C) 2021-2022 Alejandro Davis.
>>>      Copyright (C) 2022 Sharon Carter, Debra Lindsey.
>>>      This file is part of the GNU C Library.
>>>
>>>      The GNU C Library is free software; you can redistribute it ...
>>>
>>> This issue shouldn't arise for Glibc files shared with Gnulib, as
>>> they'll still follow the current policy.
>> 
>> I would prefer something along the lines “Copyright The glibc
>> Contributors”.  No year or year range, no individual names.  Listing
>> years is apparently not legally required, and naming individual authors
>> is also optional.  See:
>> 
>>   Copyright Notices in Open Source Software Projects 
>>   <https://www.linuxfoundation.org/en/blog/copyright-notices-in-open-source-software-projects/>
>
> The GCC SC suggestion is as follows:
>
> "The GNU Toolchain Authors"
> https://gcc.gnu.org/pipermail/gcc/2021-June/236217.html
>
> All files that receive DCO'd material for the first time
> would add the following line:
>
> "Copyright The GNU Toolchain Authors"
>
> in the header comment.

I had missed that.  It works for me, both the string and the rule about
adding it to files (that is, only for files with DCO contributions).

Thanks,
Florian

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

[Joseph Myers]

On Fri, 2 Jul 2021, Paul Eggert wrote:

> On 7/2/21 3:33 PM, Carlos O'Donell wrote:
> 
> > gnulib has been including non-FSF copyrighted material in various
> > modules (that include the files below) for a long time.
> 
> If gnulib-tool modifies any of those non-FSF copyright notices, then that's a
> bug that should be fixed. It doesn't modify the first one, so we should be OK
> there. (I didn't check the others.)
> 
> This raises another issue. What will be the glibc policy about putting
> copyright notices on files containing DCOed material? Will there be a separate
> copyright notice for each contributor? Linux doesn't do that - which is too
> sloppy for glibc, surely. I don't know what GCC plans to do.

I suggest using the same form as agreed by the GCC Steering Committee for 
use in GCC:

  Copyright The GNU Toolchain Authors.

with no date specified and not naming individual contributors, following 
the recommendations at 
<https://www.linuxfoundation.org/en/blog/copyright-notices-in-open-source-software-projects/>.

-- 
Joseph S. Myers
joseph@codesourcery.com

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

[Bruno Haible]

Carlos O'Donell wrote:
> gnulib already accepts such code.
> 
> gnulib has been including non-FSF copyrighted material in various 
> modules (that include the files below) for a long time.

Yes. But the article "Our need for copyright papers has not gone away"
by Richard Stallman explains, among other things, that it makes a big
difference whether a small part or a large part of the package is not
covered by copyright assignments.

In the case of Gnulib so far, it's less than 2% of the code. That's
a small part of Gnulib.

It would be much, much worse if a *large* part of Gnulib was not
covered by copyright assignments.

Similarly, Bradley Kuhn [1] reminded to think about the *long term* mix
of copyright holders.

Bruno

[1] https://sourceware.org/pipermail/libc-alpha/2021-June/128303.html

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

[Carlos O'Donell]

On 7/2/21 11:24 PM, Bruno Haible wrote:
> Carlos O'Donell wrote:
>> gnulib already accepts such code.
>>
>> gnulib has been including non-FSF copyrighted material in various 
>> modules (that include the files below) for a long time.
> 
> Yes. But the article "Our need for copyright papers has not gone away"
> by Richard Stallman explains, among other things, that it makes a big
> difference whether a small part or a large part of the package is not
> covered by copyright assignments.

Has that article been published publicly?
 
> In the case of Gnulib so far, it's less than 2% of the code. That's
> a small part of Gnulib.

Is that "small" from a legal perspective?

It's still non-FSF copyrighted code.

> It would be much, much worse if a *large* part of Gnulib was not
> covered by copyright assignments.

Do you see this changing suddenly?

> Similarly, Bradley Kuhn [1] reminded to think about the *long term* mix
> of copyright holders.

Absolutely. We should keep an eye on that.

-- 
Cheers,
Carlos.

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

[Daniel Black]

[1] https://developercertificate.org/
>

All,

As a one time attempted contributor I welcome a DCO change. The FSF
labyrinth of wiki pages and contribution options was pretty painful to
navigate, and getting a PDF a week later to print off and send back was too
much (especially as there was low interest in my patch anyway).

Bring it (DCO) on, and I might try a contribution again if I have a need.
Otherwise I'll only consider doing a bug report - the process was excessive.

Daniel Black

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

[Josh Triplett]

On Mon, Jun 14, 2021 at 02:52:03PM -0400, Carlos O'Donell wrote:
> glibc was created as part of the GNU Project but has grown to operate as
> an autonomous project. As part of the GNU Toolchain the glibc stewards
> support the gcc project policy changes presented here:
> https://gcc.gnu.org/pipermail/gcc/2021-June/236182.html
> 
> The glibc stewards are seeking input from developers to decide if the project
> should relax the requirement to assign copyright for all changes to the
> Free Software Foundation as follows:
> 
> Contributors who have an FSF Copyright Assignment wouldn't need to
> change anything.  Contributors who wish to utilize the Developer Certificate
> of Origin[1] would add a Signed-off-by message to their commit messages.

This is incredibly good news.

I've previously made *minor* contributions to glibc under my previous
employer's copyright assignment, but I'm quite interested in
contributing in the future in the absence of an assignment requirement.

I care about glibc. For context, I spent substantial time and effort in
the Rust project making it possible to do static linking with glibc, not
just with musl, because I preferred to use glibc and I wanted to make
sure that glibc was available for people to use for that use case. I'm
really looking forward to the glibc improvements to NSS that will make
static linking even more functional. I'd like to do more in this area.

I'm also interested in the long-term health of glibc, and I think this
change will enable more people to contribute, by removing a legal hurdle
that not everyone can or wants to meet, and by not discouraging
prospective contributors.

Would this step also make it possible for people to contribute
third-party Free Software code to glibc? (DCO clause (b) suggests that
it's fine to contribute code based on work under an appropriate license
that allows such contribution.)

Thank you for starting this process!

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

[Alyssa Ross]

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

On Mon, Jun 14, 2021 at 02:52:03PM -0400, Carlos O'Donell via Libc-alpha wrote:
> Community,
>
> glibc was created as part of the GNU Project but has grown to operate as
> an autonomous project. As part of the GNU Toolchain the glibc stewards
> support the gcc project policy changes presented here:
> https://gcc.gnu.org/pipermail/gcc/2021-June/236182.html
>
> The glibc stewards are seeking input from developers to decide if the project
> should relax the requirement to assign copyright for all changes to the
> Free Software Foundation as follows:
>
> Contributors who have an FSF Copyright Assignment wouldn't need to
> change anything.  Contributors who wish to utilize the Developer Certificate
> of Origin[1] would add a Signed-off-by message to their commit messages.
>
> The changes to accept patches with or without FSF copyright assignment
> would be effective on August 2nd, and would apply to all open branches.
>
> The glibc stewards, like the GCC SC, continue to affirm the principles of
> Free Software, and that will never change.
>
> glibc will continue to be developed, distributed, and licensed under the
> GNU Lesser General Public License v2.1 or any later version as
> published by the Free Software Foundation.
>
> Input on this issue is accepted until July 1st 2021.

I've recently contributed a couple of patches to glibc, and the copyright
assignment was definitely a barrier.  I have no employer or university
affiliation, so copyright wasn't an issue, and I also don't mind
assigning copyright to the FSF, because regardless of everything else
that's going on, I don't believe they're going to abuse my copyright.
But even though I should be the simplest case, it still really got in
the way of my patch, because it took 14 days after I requested the form
for me to receive it, and then another 7 days after I returned it for
it to be confirmed.  That's a long time for both the reviewer and the
contributor to keep a small patch in their head!

So I'm in favour of allowing DCO.  I'd definitely have chosen it over a
copyright assignment had it been available.  I don't particularly foresee
any negative consequences that could come of it, especially since the
FSF would probably continue to hold the vast majority of the copyright
for the foreseeable future.  And I definitely think it would help get
more contributions, because I know how close I was to just giving up.

> Signed,
> Ryan Arnold
> Paul Eggert
> Jakub Jelinek
> Maxim Kuvyrkov
> Joseph Myers
> Carlos O'Donell
>
> [1] https://developercertificate.org/
>

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

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

[Adam Sampson]

Carlos O'Donell via Libc-alpha <libc-alpha@sourceware.org> writes:

> The changes to accept patches with or without FSF copyright assignment
> would be effective on August 2nd, and would apply to all open
> branches.

This sounds like a sensible approach. One suggestion I'd make here is to
have some clear guidance on how you want to manage copyright notices in
source files as part of the development process, since there's quite a
bit of variation in practice here in other projects.

For example, do you want DCO contributors to add copyright notices to
individual files as part of their changes, or will the maintainers add
them when merging, or will you collect them in a separate file? How do
you prefer (international) names and email addresses to be formatted?

(There is some guidance on copyright notices in the GNU Information for
Maintainers, but it's mostly aimed at FSF-copyright projects at the
moment: https://www.gnu.org/prep/maintain/maintain.html#Copyright-Notices )

Thanks,

-- 
Adam Sampson <ats@offog.org>                         <http://offog.org/>

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

[Joseph Myers]

On Wed, 16 Jun 2021, Adam Sampson via Libc-alpha wrote:

> For example, do you want DCO contributors to add copyright notices to
> individual files as part of their changes, or will the maintainers add
> them when merging, or will you collect them in a separate file? How do
> you prefer (international) names and email addresses to be formatted?

What the GCC Steering Committee agreed was that non-assigned contributions 
should use notices of the form

Copyright The GNU Toolchain Authors.

with no date specified and not naming individual contributors, following 
the recommendations at 
<https://www.linuxfoundation.org/en/blog/copyright-notices-in-open-source-software-projects/>.

-- 
Joseph S. Myers
joseph@codesourcery.com

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

[Phil Blundell]

On Mon, Jun 14, 2021 at 02:52:03PM -0400, Carlos O'Donell via Libc-alpha wrote:
> The glibc stewards are seeking input from developers to decide if the project
> should relax the requirement to assign copyright for all changes to the
> Free Software Foundation as follows:

I support this proposal.

Phil

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

[Bradley M. Kuhn]

Dear glibc Software Developer Community,

I have read this thread with interest, and I hope that it is acceptable for
me to share my comments.  Even though I personally have never put code into
glibc, I *have* helped over the years with various issues around licensing
in glibc (before the abrupt end to my affiliation with the FSF in 2019).  I
hope that past work to help glibc, and my general work in the Free and Open
Source Software community on copyleft enforcement, compliance, and policy
means that my opinions here are useful.  However, if decision-making input
here is welcome only from those who have code in glibc, I understand
completely and, if so, please ignore this interruption!

     * * *

Much of the discussion I've seen here has contrasted the DCO with a
copyright assignment process.  I am particularly appreciative for those who
have pointed out that's not the case: the DCO and copyright assignment
policies are orthogonal issues.  I fully support use of a DCO for glibc,
although I recommend the Samba one myself (See
<https://www.samba.org/samba/devel/copyright-policy.html>).  Regardless of
which DCO you pick, you could implement most any DCO and keep copyright
assignment; the two ultimately have little to do with each other.

The key quesiton at hand, thus, is whether to continue or curtail the
mandated copyright assignment to FSF for regular/frequent contributors.
While I have previously assigned my own copyright to the FSF (*both* as
"work-for-hire" and "signed assignment form" manner), I personally wouldn't
assign any new copyrights to FSF at this time for various reasons.
Therefore, I am personally sympathetic to those of you who do not want to
assign anymore.

Nevertheless, I feel much of this discussion is missing a few of the key
nuances that are highly relevant to ending the copyright assignment mandate.
Most importantly, the current proposal does not make recommendations on what
developers should do (and/or how they should organize) to assure that they
will ultimately keep their own copyrights when the existing copyright
assignment legal infrastructure starts to atrophy after the policy change.
By default, most copyrights revert to the employer when you contribute to a
codebase as part of your job.

A few commentors on this list claim that *in theory*, this policy change
opens a world of possibility and diversity of where the copyright ownership
lands.  However, given work-for-hire doctrine in the USA (and similar rules
around the world), it's highly unlikely that theory will come to fruition in
practice without a clear plan.  Most future contributions may well revert to
emloyer-owned.  Only collective organization by developers *before* the
policy change takes effect can prevent that.

I thus strongly urge caution, and more careful consideration about the
ramifications of where copyright will land going forward, including (but not
exclusively limited to) a long extension of the current July 1st deadline.

Three questions that I have yet to see addressed in this thread include: 

      * What do we anticipate the long term mix of copyright holders (say, 5
        years from now) will be in glibc once copyright assignment is wholly
        optional?
 
      * Will whoever holds the future copyright be willing to enforce the
        LGPL?  (That's particular important given that LGPL/GPL violations
        are quite common on glibc.)

      * Will that copyright holder adhere to well-established community
        principles and a committment to the public good when doing that
        enforcement?

These are just a few questions among dozens that will quickly become
paramount once glibc starts its move to a primarily multi-copyright-held
(from a primarily overwhelming-majority-single-copyright-held) project.  Of
course, glibc isn't the only project facing these questions.  As such, in
response to these recent changes under consideration by GCC, glibc, and
gnulib, I've written a comprehensive essay that (while quite long) raises
all the questions and concerns that I have about this change.  If you're
interested, you can read it here:
https://sfconservancy.org/blog/2021/jun/30/who-should-own-foss-copyrights/

I also offer myself and my colleagues at Software Freedom Conservancy as a
resource to help you investigate these questions if you're interested (as
one of my colleague already did for (see
<https://gcc.gnu.org/pipermail/gcc/2021-June/236257.html>) Personally, I've
spent a career studying the policy questions and observing their
consequences in real world scenarios, and organizationally Conservancy has
done the same.  I'd be thrilled to share that knowledge with you.

Finally, I saw a few folks in this thread wondering about "what the lawyers
have said" or what they think.  Keep in mind: I personally am not a lawyer,
and Conservancy is not a law firm and we won't and cannot give you legal
advice.  However, I do urge you all to talk to your lawyers about this.

However, keep in mind also that "the lawyers at work" are the lawyers for
your company, not for you personally or the glibc project.  As such, lawyers
at your workplace will gladly give you legal advice that is in the best
interest of the company, but they don't represent your interests nor glibc's
interests.  It's important that you have someone looking out for *your*
legal interests and the legal interests of glibc as a project.  Sometimes
those interests will align with your employer, and sometimes they won't.  If
you're looking for a lawyer for yourself, while I don't know anyone who does
such work pro-bono, I do know a lot of lawyers who would gladly give you a
"low bono" rate.  If you write my privately, I'll try to give you a
recommendation of an attorney to reach out to.

In closing, I ask everyone to consider the efficacy of, enforcement of, and
future compliance with copyleft licenses in making this momentous decision.
Thanks for your time in reading this email, and hopefully -- yes, I know
it's a wall of text -- in reading my longer essay on the subject:
 https://sfconservancy.org/blog/2021/jun/30/who-should-own-foss-copyrights/

Sincerely,
-- 
Bradley M. Kuhn - he/him
Policy Fellow & Hacker-in-Residence at Software Freedom Conservancy
========================================================================
Become a Conservancy Supporter today: https://sfconservancy.org/supporter

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

[Siddhesh Poyarekar]

On 7/1/21 3:24 AM, Bradley M. Kuhn wrote:
> Dear glibc Software Developer Community,

Thank you for writing this and the blog post.  I share my 2p as a long 
time contributor but I'm not ashamed to admit that there are others who 
would have far more educated opinions.

> I have read this thread with interest, and I hope that it is acceptable for
> me to share my comments.  Even though I personally have never put code into
> glibc, I *have* helped over the years with various issues around licensing
> in glibc (before the abrupt end to my affiliation with the FSF in 2019).  I
> hope that past work to help glibc, and my general work in the Free and Open
> Source Software community on copyleft enforcement, compliance, and policy
> means that my opinions here are useful.  However, if decision-making input
> here is welcome only from those who have code in glibc, I understand
> completely and, if so, please ignore this interruption!
> 
>       * * *
> 
> Much of the discussion I've seen here has contrasted the DCO with a
> copyright assignment process.  I am particularly appreciative for those who
> have pointed out that's not the case: the DCO and copyright assignment
> policies are orthogonal issues.  I fully support use of a DCO for glibc,
> although I recommend the Samba one myself (See
> <https://www.samba.org/samba/devel/copyright-policy.html>).  Regardless of
> which DCO you pick, you could implement most any DCO and keep copyright
> assignment; the two ultimately have little to do with each other.

This looks quite good.  There would be practical concerns, i.e. who 
becomes the custodian of such records, but they're not insurmountable.

> The key quesiton at hand, thus, is whether to continue or curtail the
> mandated copyright assignment to FSF for regular/frequent contributors.
> While I have previously assigned my own copyright to the FSF (*both* as
> "work-for-hire" and "signed assignment form" manner), I personally wouldn't
> assign any new copyrights to FSF at this time for various reasons.
> Therefore, I am personally sympathetic to those of you who do not want to
> assign anymore.
> 
> Nevertheless, I feel much of this discussion is missing a few of the key
> nuances that are highly relevant to ending the copyright assignment mandate.
> Most importantly, the current proposal does not make recommendations on what
> developers should do (and/or how they should organize) to assure that they
> will ultimately keep their own copyrights when the existing copyright
> assignment legal infrastructure starts to atrophy after the policy change.
> By default, most copyrights revert to the employer when you contribute to a
> codebase as part of your job.
> 
> A few commentors on this list claim that *in theory*, this policy change
> opens a world of possibility and diversity of where the copyright ownership
> lands.  However, given work-for-hire doctrine in the USA (and similar rules
> around the world), it's highly unlikely that theory will come to fruition in
> practice without a clear plan.  Most future contributions may well revert to
> emloyer-owned.  Only collective organization by developers *before* the
> policy change takes effect can prevent that.

I strongly believe dropping the assignment requirement makes it easier 
for developers to get involved.  However, I don't see that changing the 
structure of copyright ownership of the glibc code base by much in the 
short or medium term.

The change in copyright ownership may change in the long term, but given 
the current contributions, I still expect the majority to stay with the 
FSF and a handful of companies, some of whom have been targets in the 
past of frivolous copyright claims in Open Source code.  That won't be 
too different from the Linux project, where a bulk of the code in the 
core kernel originates from a handful of companies.  If anything, it's 
likely to be even more constrained.

> I thus strongly urge caution, and more careful consideration about the
> ramifications of where copyright will land going forward, including (but not
> exclusively limited to) a long extension of the current July 1st deadline.
> 
> Three questions that I have yet to see addressed in this thread include:
> 
>        * What do we anticipate the long term mix of copyright holders (say, 5
>          years from now) will be in glibc once copyright assignment is wholly
>          optional?

Like I said above, in the long term the mix may change, but I still 
don't expect the FSF ownership to be diluted by much for various 
reasons.  Even if there were dilution, I don't expect it to diverge too 
much from the handful of organizations that currently pitch in to 
maintain glibc.  I think there are predictable patterns to those 
contributions too in terms of which sources are touched by which 
individuals/organizations.

>        * Will whoever holds the future copyright be willing to enforce the
>          LGPL?  (That's particular important given that LGPL/GPL violations
>          are quite common on glibc.)
> 
>        * Will that copyright holder adhere to well-established community
>          principles and a committment to the public good when doing that
>          enforcement?

I believe the FSF would have enough of a copyright stake in glibc even 
in the long term to have the means and the incentive to do that. However 
like you mentioned in your blog post (and I've heard from others in a 
significantly less polite manner and long before the internal crisis you 
mentioned), the FSF isn't exactly rushing to act on violations and 
enforcement.

I'm under no illusion that for profit companies would actively seek out 
violators and help get them on course to compliance since it does not 
affect their core business.  The SFC enforcement coalition your 
colleague mentioned on the gcc list is a great option IMO.

Thanks,
Siddhesh

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

[Bradley M. Kuhn]

Siddhesh Poyarekar wrote at 22:24 (PDT) on Wednesday:
> I strongly believe dropping the assignment requirement makes it easier for
> developers to get involved.

I absolutely agree, and as I indicated in my longer essay, I personally
prefer a model where there is a good mix of copyrights held by individual
contributors and charities both.  That is not a new position of mine.  My
affiliation with the FSF ended in 2019, but when I previously had
affiliation with the FSF, I was one of the few internal voices who advocated
to relax the copyright assignment processes for GCC, *provided that*
individuals rather companies held the non-FSF-assigned copyrights.  I argued
for that internally at the FSF on a semi-regular basis from 2002 right up
until a few moths before my affiliation with the FSF ended in 2019.

*However* … 

> I still don't expect the FSF ownership to be diluted by much for various
> reasons.

I think we can't know that for sure one way or the other — unless someone
does the work to:

  (a) comb and collate VCS logs to document who the major contributors are,
  (b) figure out who their employers are (or were, or will be),
  (c) clearly examine how the copyright assignment / disclaimer of copyright
      relationships between those companies and the FSF are currently
      structured, and
  (d) do an analysis of what's likely to happen to those agreements once the
      copyright assignment requirement is lifted.

Keep in mind that the copyright assignment/disclaimer arrangements have many
forms and structures; IIUC, most can be revoked.  Furthermore, I note that
the deadline day for input on this momentous change is nearing its end, and
there are no statements on this thread from the well-known major employers
involved in glibc about what their intended copyright policy if the FSF
copyright assignment mandate is lifted.

Absent assurances and more information, we must assume the worst case: that
the all new copyrights are owned by the contributors' employers as soon as
the copyright assignment mandate is lifted.

> That won't be too different from the Linux project, where a bulk of the
> code in the core kernel originates from a handful of companies.

This has led to many bad outcomes for Linux.  While those outcomes can and
have been (mostly) mitigated, I don't recommend glibc aim to emulate that
model.

> Even if there were dilution, I don't expect it to diverge too much from
> the handful of organizations that currently pitch in to maintain glibc.

Those organizations likely do not share a belief that copyleft should be
enforced for the good of downstream users, so I think that point is bad
news, not good news … which relates to your later point …
> I'm under no illusion that for profit companies would actively seek out
> violators and help get them on course to compliance since it does not
> affect their core business.

… with which I agree.

Meanwhile, on the matter of potential Conservancy involvement:
> The SFC enforcement coalition your colleague mentioned on the gcc list is
> a great option IMO.

I'm glad you think so, and Conservancy does have that form of arrangement
with the Debian project.  Debian's primary home in the USA is Software in
the Public Interest, but they have a limited arrangement with Conservancy
regarding voluntary copyright assignments for some contributors, and
enforcement proxy agreements for those who own their copyrights.  The best
resource for how that program works is the original announcements:
           https://sfconservancy.org/news/2015/aug/17/debian/
           https://sfconservancy.org/blog/2015/aug/17/debian/

Most importantly, keep in mind that major Debian contributors approached
Conservancy to request this.  Conservancy doesn't unilaterally start these
kinds of programs; we do them when project contributors ask for them.  We've
offered to help generally, but no one has asked us for any specific
assistance in the case of glibc, GCC, and gnulib.  Beyond general comments
and thoughts (such as this email), we *wouldn't* impose ourselves on the
situation unless explicitly requested.  IOW, at the moment, I and
Conservancy aren't involved, other than to give our opinions as folks
knowledgeable on the subject — in response to the public call for comment:
    https://sourceware.org/pipermail/libc-alpha/2021-June/127581.html

> I still expect the majority [of the copyright] … to stay with … a handful
> of companies, some of whom have been targets in the past of frivolous
> copyright claims in Open Source code.

I suppose it's possible that companies who contribute to glibc have also
faced frivolous copyright claims on FOSS.  (However, such incidents are
extremely rare, though — and, I'm admittedly wondering if you're referencing
the same widely exaggerated tale that I'm thinking of.)  Regardless, I think
it's a moot point.  Such a situation doesn't imply those companies will
later have the goal of defending the rights of users under copyleft.  If
relevant at all, IMO, it cuts the other way: those companies may seek
copyrights for escalation/counter-claims against any enforcement action
(even a legitimate one brought to defend users' rights).  Note that, when
they enforce the LGPL and GPL, Conservancy and FSF are both accused of being
“copyright trolls”, and the Defendants *always* call those claims “frivolous”.
-- 
Bradley M. Kuhn - he/him
Policy Fellow & Hacker-in-Residence at Software Freedom Conservancy
========================================================================
Become a Conservancy Supporter today: https://sfconservancy.org/supporter

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

[Siddhesh Poyarekar]

On 7/2/21 1:03 AM, Bradley M. Kuhn wrote:
> Keep in mind that the copyright assignment/disclaimer arrangements have many
> forms and structures; IIUC, most can be revoked.  Furthermore, I note that
> the deadline day for input on this momentous change is nearing its end, and
> there are no statements on this thread from the well-known major employers
> involved in glibc about what their intended copyright policy if the FSF
> copyright assignment mandate is lifted.

For commercial distribution vendors**, I suspect it is not as easy a 
decision to withdraw copyright assignment since their contribution to 
GNU goes beyond gcc and glibc.  For hardware vendors (who form the other 
large contingent of contributors) maybe it's not as hard a decision, but 
it still involves getting legal to evaluate the change and initiate the 
process so I'm not entirely sure given that nobody has actually moved 
yet AFAICT.

> Absent assurances and more information, we must assume the worst case: that
> the all new copyrights are owned by the contributors' employers as soon as
> the copyright assignment mandate is lifted.

But for that their assignment has to be terminated, no?  If nobody has 
moved to do that, the worst case assumption ought to be a little more 
benign, i.e. companies start evaluating and withdrawing their 
assignments and the change happens more slowly over the coming months/years.

Regardless of that, I reckon the FSF will always have enough of a 
copyright stake to allow enforcing copyleft.  The glibc code base has 
legally significant artifacts at least from the early 90s that have 
survived to this date; that's 30 years.

> I suppose it's possible that companies who contribute to glibc have also
> faced frivolous copyright claims on FOSS.  (However, such incidents are
> extremely rare, though — and, I'm admittedly wondering if you're referencing
> the same widely exaggerated tale that I'm thinking of.)  Regardless, I think
> it's a moot point.  Such a situation doesn't imply those companies will
> later have the goal of defending the rights of users under copyleft.  If
> relevant at all, IMO, it cuts the other way: those companies may seek
> copyrights for escalation/counter-claims against any enforcement action
> (even a legitimate one brought to defend users' rights).  Note that, when

/me nods.  Based on my limited knowledge from asking around, it doesn't 
look like anybody has moved to terminate their assignments. 
Unfortunately I am not privy to the assignment file or the details of 
contracts with the FSF so I don't know for sure.

Siddhesh

** I am not speaking for my employer (Red Hat) and this is my personal 
impression based on my understanding of how distributions work.

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

[Eli Zaretskii]

> From: siddhesh@gotplt.org (Siddhesh Poyarekar)
> Date: Fri, 2 Jul 2021 08:59:10 +0530
> 
> > Absent assurances and more information, we must assume the worst case: that
> > the all new copyrights are owned by the contributors' employers as soon as
> > the copyright assignment mandate is lifted.
> 
> But for that their assignment has to be terminated, no?  If nobody has 
> moved to do that

Actually, one contributor already did.

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

[Alexandre Oliva]

Hello, Bradley,

Thank you for taking the time to try to influence this community in a
direction that is more conducive to our shared goals of promoting
software freeom than what is being considered.

I've remained mainly silent in this debate, because I feel the climate
and the perceived allegiances I hold, and the emotional rather than
strategic motivations behind these pressure campaigns, are unlikely to
help my arguments be heard, or, worse, are likely to have them taken as
something to be opposed.

I'm glad someone like you, who AFAICT is not afflicted by these
perceptions, has made so clear the risks of corporate takeover, and of
copyleft dilution into meaninglessness.  Thank for having done this.

I'd like to subscribe to your recommendation that we don't make this
decision in a hurry, and that we don't take lightly the loss of the
primary leverage we have to keep copyrights, and thus copyleft
enforcement powers, in the hands of organizations that can normally be
counted on to pursue them, and to amount to a credible threat to those
considering deviating from them, instead of approaching these matters
under the shadow of usual corporate interests.


Even if some believe a policy change away from assignments to the FSF
may make things better, they should consider whether they'd really
prefer contributors' employers to keep the copyrights instead.  As soon
as the possibility of not contributing copyrights is instated, employers
will have little reason to give much consideration to employee's
requests for assignments or disclaimers.

The leverage will be gone, and existing contracts in which employees
counted on project's requirements and consequent corporate assignments
to land copyrights in hands that are aligned with and committed to
software freedom, may be turned into corporate-held copyrights, without
any actions o even awareness by employees, by having the corporation
unilaterally terminating the assignment for future contributions.


Some may welcome these policy changes as a means to defy and hurt the
FSF and RMS, but ultimately it will hurt harder the project's goals, and
those of its contributors.  I'm sure those who are seeding dissent from
behind the curtains, spreading lies, reinforcing incorrect perceptions,
and promoting self-defeating strategies within our ranks, don't mind at
all if we hurt each other and our projects.

-- 
Alexandre Oliva, happy hacker                https://FSFLA.org/blogs/lxo/
   Free Software Activist                       GNU Toolchain Engineer
Disinformation flourishes because many people care deeply about injustice
but very few check the facts.  Ask me about <https://stallmansupport.org>

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

[Florian Weimer]

* Bradley M. Kuhn:

> Nevertheless, I feel much of this discussion is missing a few of the key
> nuances that are highly relevant to ending the copyright assignment mandate.
> Most importantly, the current proposal does not make recommendations on what
> developers should do (and/or how they should organize) to assure that they
> will ultimately keep their own copyrights when the existing copyright
> assignment legal infrastructure starts to atrophy after the policy change.
> By default, most copyrights revert to the employer when you contribute to a
> codebase as part of your job.

I think in the context of glibc, with copyright assignment to the FSF,
this does not strike me as particularly relevant, given where we are
today.

The current version of the GPL explicitly exempts workers from copyleft
protection, so that they do not enjoy any software freedoms at all:

| You may convey covered works to others for the sole purpose of having
| them make modifications exclusively for you, or provide you with
| facilities for running those works, provided that you comply with the
| terms of this License in conveying all material for which you do not
| control copyright.  Those thus making or running the covered works for
| you must do so exclusively on your behalf, under your direction and
| control, on terms that prohibit them from making any copies of your
| copyrighted material outside their relationship with you.

Version 2 of the GPL does not have comparable language, so the situation
was much more murky there.

Consequently, I don't think that for those of us who are concerned about
workers' rights, employers bypassing copyleft, and such like, the FSF is
the right organization to assign copyrights to.

Thanks,
Florian

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

[Mark Wielaard]

Hi,

On Mon, Jun 14, 2021 at 02:52:03PM -0400, Carlos O'Donell wrote:
> glibc was created as part of the GNU Project but has grown to operate as
> an autonomous project. As part of the GNU Toolchain the glibc stewards
> support the gcc project policy changes presented here:
> https://gcc.gnu.org/pipermail/gcc/2021-June/236182.html
> 
> The glibc stewards are seeking input from developers to decide if the project
> should relax the requirement to assign copyright for all changes to the
> Free Software Foundation as follows:
> 
> Contributors who have an FSF Copyright Assignment wouldn't need to
> change anything.  Contributors who wish to utilize the Developer Certificate
> of Origin[1] would add a Signed-off-by message to their commit messages.
> 
> The changes to accept patches with or without FSF copyright assignment
> would be effective on August 2nd, and would apply to all open branches.

I talked to some of you already off-list but realized I hadn't
responded publicly. I don't really like this proposal because it is
vague on details and policy. And it doesn't mention any specific goal
for this policy change. This makes it so that the discussion is
somewhat random IMHO because people are just inserting their own goals
and assume this proposal is for or against those.

I noticed that the proposal is signed by just a subset of the
stewards. What is the opinion of the other stewards? And I would
really like to know the opinion of FSF legal on this proposal.

Personally I contribute to glibc and some other GNU projects because
we are all equal participants (when it comes to the rights we have to
the project code) and have the FSF as legal guardian to fall back on
and who we can use to look out for the users, so they will always have
the possibility to get the full corresponding source code of our work
to use and modify as they want. And I know that the FSF will be
reasonable and fair about it:
https://www.fsf.org/licensing/enforcement-principles

The above is possible because of the copyright assignments and maybe
even more importantly the company disclaimers we provide to the FSF. I
appreciate that those assignments are sometimes a bit of work, but
recently having done several personal copyright assignments myself it
is a fairly smooth process, taking just a couple of days. Of course if
you also need a company disclaimer because your employer makes claims
on your work and doesn't have one on file with the FSF might take a
bit more work. But having done that it mostly is figuring out who can
sign the disclaimer. And it makes sure it is not just you who can
freely assign those right to the FSF, but also that the general public
will permanently and irrevocably get those rights.

I don't feel the proposed developer certificate of origin provides
those same guarantees. Especially if we also won't require a company
disclaimer anymore. I fear it will lead to unclear copyright ownership
which might make compliance impossible leading to users not having a
clear contact point when they are looking for the sources to our
works. Or the opposite where a company acquires a substantial amount
of copyright in our work and starts to randomly enforce it and/or
scare their customers/users to "buy" compliance.

There are also practical issues where it will be more difficult to
share code with other GNU projects and/or change the version or
exception statements used in the code. Especially with the current
proposed text of the linux kernel DCO. It would be good to at least
use a text that is tailored to the GNU project.

And as people have pointed out just requiring the "signed-off-by" line
without requiring people explain why or how they are complying with
the DCO (who is the copyright holder? which clause of the DCO are you
complying with?) makes it really hard to track the legal status of the
code.

I can certainly see how a DCO could be helpful with occasional drive
by contributions without creating full chaos as I describe above if
the text was more clear and the processes around it more specific of
how they comply with the DCO and which copyright holder they
represent. But I hope we will still require people making sustainable
contributions (and who want to become maintainers with commit rights)
to assign their copyright and where necessary (because the contributor
doesn't own the work they want to contribute) require company
disclaimers.

Cheers,

Mark