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

[Siddhesh Poyarekar <siddhesh@gotplt.org>]

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