Seeking input from developers: glibc copyright assignment policy.

Seeking input from developers: glibc copyright assignment policy.

[Paul Eggert]

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.

Here's a copy of the email seeking input from developers on libc-alpha.

-----

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.

[Bruno Haible]

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

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

[Eric Blake]

On Mon, Jun 14, 2021 at 01:39:26PM -0700, Paul Eggert wrote:
> 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.

I would like to make sure the FSF legal department doesn't see any
holes in the plan, but I'm certainly okay as going on record as being
in favor of the plan.  I recall how long it took for me to get
permission to sign assignment papers from my previous employer, for
work I was doing in my spare time, and being able to use the DCO
instead would have made my efforts easier at that time.  (My current
employer already has a blanket copyright assignment on file for all
employees, but not everyone has a company that willing to promote open
source involvement.)

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3266
Virtualization:  qemu.org | libvirt.org

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

[Paul Smith]

On Tue, 2021-06-15 at 07:03 -0500, Eric Blake wrote:
> I recall how long it took for me to get permission to sign assignment
> papers from my previous employer, for work I was doing in my spare
> time, and being able to use the DCO instead would have made my
> efforts easier at that time.

This is what concerns me (not necessarily in Eric's case per se but in
general).  I worry that people think that a DCO is a hassle-free
replacement for an employer's copyright assignment.  Maybe, in some
jurisdictions, it even can be.

But as far as I'm aware in the U.S. (and other countries) you can't
just declare that your employer doesn't have any copyright to work you
do, even on your own time.  Most employment contracts make this clear
and even when they don't spell it out I think there's a presumption
that it is the case, certainly for salaried employees.

So, I just worry people will simply sign the DCO and call it good when
they don't actually have legal rights to do that.  Sure, that may
reduce liability for copyright infringement on the project: an employer
would have to go after the individual instead, but that wouldn't
prevent the project from having to remove the infringing code and all
code that could be considered derivative from it, which could be an
enormous hassle.

Maybe I'm wrong about how the DCO works but it greatly concerns me that
we would lose this safety net: rather than doing the work up-front
directed by people who understand the law, we're distributing this work
to random individuals and relying on each of them to fully understand
the legal questions and get it right for their situation... and leave
the project holding the bag if they don't.

Have there been any opinions or whitepapers published by FOSS
organizations regarding DCOs vs. assignments, discussing their benefits
and risks?

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

[Bruno Haible]

Paul Smith wrote:
> I worry that people think that a DCO is a hassle-free
> replacement for an employer's copyright assignment.  Maybe, in some
> jurisdictions, it even can be.
> 
> But as far as I'm aware in the U.S. (and other countries) you can't
> just declare that your employer doesn't have any copyright to work you
> do, even on your own time.

Yes, it depends on the jurisdiction. In Germany, the law gives the
employee the copyright on works created on his own time (§ 15 UrhG,
§ 69b UrhG, § 2.1 GG); the employment contract can influence further
details. The situation appears to be very different in the U.S.

Bruno

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

[Eli Zaretskii]

> From: Paul Smith <psmith@gnu.org>
> Date: Tue, 15 Jun 2021 12:32:35 -0400
> 
> On Tue, 2021-06-15 at 07:03 -0500, Eric Blake wrote:
> > I recall how long it took for me to get permission to sign assignment
> > papers from my previous employer, for work I was doing in my spare
> > time, and being able to use the DCO instead would have made my
> > efforts easier at that time.
> 
> This is what concerns me (not necessarily in Eric's case per se but in
> general).  I worry that people think that a DCO is a hassle-free
> replacement for an employer's copyright assignment.  Maybe, in some
> jurisdictions, it even can be.

In addition to what Paul Smith and Bruno Haible wrote, there is IMO
one other important aspect to be considered, which is specific to
Gnulib.  Unlike GCC, glibc, and many other projects, which are
basically separate, and therefore their decisions in this matter
affect only them and their users, Gnulib is different.  Gnulib is not
a separate project, it is in effect a collection of library functions
from which dozens of other GNU projects borrow code for their
distributions.  Thus, any changes in this matter that Gnulib
developers decide upon will affect all those "client" projects as
well.

For example, Emacs imports more than 200 source files from Gnulib, and
distributes them as part of its release tarballs and in its Git
repository.  If Gnulib folks decide that they can accept contributions
under DCO, does it mean Emacs will be unable to change its license to
GPL of version greater than 3?  Does it mean Emacs will bear part of
the risk of distributing sources whose DCO is invalid (for reasons
described by Paul Smith)?  (And it doesn't help that some/much of the
Gnulib code is taken from glibc, which will probably decide to follow
GCC's example.)

Given these aspects, I submit that Gnulib developers shouldn't make
these kinds of decisions without consulting with other GNU projects.

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

[Pádraig Brady]

On 15/06/2021 13:03, Eric Blake wrote:
> On Mon, Jun 14, 2021 at 01:39:26PM -0700, Paul Eggert wrote:
>> 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.
> 
> I would like to make sure the FSF legal department doesn't see any
> holes in the plan, but I'm certainly okay as going on record as being
> in favor of the plan.

I am in favor of the plan also.
I feel copyright assignment is a significant _initial_ hurdle to contributions,
where the potential to deter contribution outweighs any potential advantages.

> I recall how long it took for me to get
> permission to sign assignment papers from my previous employer, for
> work I was doing in my spare time, and being able to use the DCO
> instead would have made my efforts easier at that time.  (My current
> employer already has a blanket copyright assignment on file for all
> employees, but not everyone has a company that willing to promote open
> source involvement.)

Yes the fact that one needs to repeat this process
as one changes employers is very awkward.
(In my case it was the reverse, in going from a company with
blanket copyright assignment, to one where I needed to
navigate the internal processes to get an assignment.)

I do wonder how diligent people are in general in this regard anyway.
I.e. how valid all current assignments are given the
frequency of employer changes and the awkwardness involved.

thanks,
Pádraig

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

[Paul Smith]

On Tue, 2021-06-15 at 22:08 +0100, Pádraig Brady wrote:
> Yes the fact that one needs to repeat this process as one changes
> employers is very awkward.

This is exactly what I was worried about with my previous message:
people saying "it's awkward to get my employer to assign copyright so
I'd rather use a DCO" when they are not legally allowed to do that.

A DCO is not a magic bullet.  If your employer has copyright to the
changes you made then the DCO is useless to you because the ownership
is not yours to certify; you'll STILL have to get your employer to
agree to it.  If you have the copyright yourself then you don't need
your employer to sign anything in the first place!

Allowing contributors to follow a simpler process doesn't make the
situation less complicated, it just makes it easier to ignore.  But
ignoring it doesn't make it go away.

The assignment is awkward, and it is extra effort, but that effort is
not useless or wasted.  IMO it's important for the project that people
pay attention to this and handle it BEFORE their code is accepted.

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

[Dmitry V. Levin]

On Mon, Jun 14, 2021 at 01:39:26PM -0700, Paul Eggert wrote:
> 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.

Here is the list of affected gnulib modules:

$ git grep -A1 ^Maintainer: modules/ | sed -n '/glibc/ s/-[^-]*$//p'
modules/alphasort
modules/argp
modules/atoll
modules/crypto/md5
modules/crypto/md5-buffer
modules/dynarray
modules/eloop-threshold
modules/error
modules/euidaccess
modules/filename
modules/fnmatch
modules/fnmatch-h
modules/getcwd
modules/getopt-gnu
modules/getopt-posix
modules/getpass
modules/getpass-gnu
modules/getsubopt
modules/glob
modules/glob-h
modules/idx
modules/inet_ntop
modules/inet_pton
modules/memchr
modules/memcmp
modules/memrchr
modules/mktime
modules/nstrftime
modules/obstack
modules/posix_spawn
modules/posix_spawn-internal
modules/posix_spawn_file_actions_addclose
modules/posix_spawn_file_actions_adddup2
modules/posix_spawn_file_actions_addopen
modules/posix_spawn_file_actions_destroy
modules/posix_spawn_file_actions_init
modules/posix_spawnattr_destroy
modules/posix_spawnattr_getflags
modules/posix_spawnattr_getpgroup
modules/posix_spawnattr_getschedparam
modules/posix_spawnattr_getschedpolicy
modules/posix_spawnattr_getsigdefault
modules/posix_spawnattr_getsigmask
modules/posix_spawnattr_init
modules/posix_spawnattr_setflags
modules/posix_spawnattr_setpgroup
modules/posix_spawnattr_setschedparam
modules/posix_spawnattr_setschedpolicy
modules/posix_spawnattr_setsigdefault
modules/posix_spawnattr_setsigmask
modules/posix_spawnp
modules/pt_chown
modules/putenv
modules/random
modules/random_r
modules/rawmemchr
modules/scandir
modules/scratch_buffer
modules/spawn
modules/stpcpy
modules/stpncpy
modules/strchrnul
modules/strcspn
modules/strdup
modules/strdup-posix
modules/strndup
modules/strpbrk
modules/strptime
modules/strsignal
modules/strtok_r
modules/strtol
modules/strtoll
modules/strtoul
modules/strtoull
modules/strverscmp
modules/timegm
modules/tsearch


-- 
ldv