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

[Bruno Haible <bruno@clisp.org>]

Hi Paul,

> A proposal to change the glibc copyright assignment policy is being 
> circulated on libc-alpha. The email thread starts at 
> <https://sourceware.org/pipermail/libc-alpha/2021-June/127581.html>, and 
> the text of the email seeking input is at the end of this message.
> 
> I'm sending this to bug-gnulib because we copy some files directly from 
> glibc and eventually I expect these files to be affected. The simplest 
> approach I see for Gnulib is to adopt glibc's policy, at least for files 
> or code copied from glibc.

The obvious benefit of GCC's and glibc's new contributions policy is
that it will allow more contributions in the same time, and thus "boost"
the projects.

The drawbacks are not so easy to see, but they are important as well:

  * How to respond to contributors who withdraw their contribution,
    long after it was integrated?

    This happened to Linux libc5 at some point; H.J. Lu had to back
    out the contribution. If this happened today, in GCC or glibc,
    Red Hat would probably be able to spend lawyer investment or
    developer investment, to fix the damage. But Gnulib is more of
    a GNU project than a Red Hat project; I'm not sure Red Hat would
    protect Gnulib in case such a situation arises.

  * [1] brings up the argument of university students in the US, who
    have problem doing the copyright work with the FSF. If the new
    policy has the effect that such people now contribute _without_
    the consent of their university, we have contributions that can
    be attacked in court.

  * How to respond to copyright violations? It is generally simpler
    to approach or sue the violator when there is only one copyright
    holder, see [2]. Even signalling a copyright violation to a
    company is simpler when there is only one copyright holder [3].
    How is license enforcement going in practice when there are
    multiple copyright holders? And when one of them is already
    deceased?

    I think for this topic we should get input from the FSF,
    the Software Freedom Conservancy, and/or gpl-violations.org.

  * How to manage an upgrade to a license that is better suited in the
    future? Copyright laws change over the years, societies change,
    and packages that can adapt their license to changed realities are
    at an advantage.

  * Free Software has grown in economic importance over the last 10
    years. Most software products now include a significant proportion
    of free software. Threats are therefore bigger than they
    were 10 years ago. In this situation, it appears to me that formal
    contracts provide a better legal basis than Signed-off-by messages.
    I don't think IBM would have won the legal battle against SCO [4] if
    there had not been formal contracts.

In Gnulib, we (me included) haven't been very strict on this topic [5].
But switching to a different policy is a bigger change than just being
lazy on a few files.

That was my opinion. What is the Chief GNUisance's opinion?

Bruno

[1] https://sourceware.org/pipermail/libc-alpha/2021-June/127586.html
[2] https://www.gnu.org/licenses/why-assign.en.html
[3] https://www.oracle.com/de/legal/copyright.html
[4] https://en.wikipedia.org/wiki/SCO%E2%80%93Linux_disputes
[5] https://lists.gnu.org/archive/html/bug-gnulib/2021-05/msg00072.html