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

[Carlos O'Donell <carlos@redhat.com>]

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.