Update to glibc copyright assignment policy

Update to glibc copyright assignment policy

[Carlos O'Donell via Libc-alpha]

glibc was created as part of the GNU Project but has grown to operate
as an autonomous project.

The glibc stewards have decided to relax the requirement to assign
copyright for all changes to the Free Software Foundation. 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 change is consistent with the
practices of many other major Free Software projects, such as the
Linux kernel, and GCC [1].

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

The changes to accept patches with or without FSF copyright assignment
will be effective after August 2nd, and will apply to all open
branches. Code shared with other GNU packages via Gnulib will continue
to require assignment to the FSF.

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

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

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

Re: Update to glibc copyright assignment policy

[Siddhesh Poyarekar]

On 7/29/21 1:20 AM, Carlos O'Donell via Libc-alpha wrote:
> branches. Code shared with other GNU packages via Gnulib will continue
> to require assignment to the FSF.

Does that mean we cannot touch the code shared with gnulib if we do not 
assign copyright to the FSF?  Or does it mean that if/when that happens, 
we will stop syncing those bits with gnulib?

Siddhesh

Re: Update to glibc copyright assignment policy

[Carlos O'Donell via Libc-alpha]

On 7/29/21 6:25 AM, Siddhesh Poyarekar wrote:
> On 7/29/21 1:20 AM, Carlos O'Donell via Libc-alpha wrote:
>> branches. Code shared with other GNU packages via Gnulib will
>> continue to require assignment to the FSF.
> 
> Does that mean we cannot touch the code shared with gnulib if we do
> not assign copyright to the FSF?  Or does it mean that if/when that
> happens, we will stop syncing those bits with gnulib?

The code shared with gnulib carries with it an existing obligation
to the gnulib community that we maintain the existing copyright
protocol for those files to honour that obligation.

My suggestion is that we as a community in glibc need to decide,
on a file-by-file basis what we are going to do. I'm open to other
alternatives too, the following 2 steps are just my suggestion.

(1) Update https://sourceware.org/glibc/wiki/SharedSourceFiles with
    the actual file status.

(2) Make a decision.

* Find a new way to share the code with minimal impact.
  - Carve out glibc-related functions into distinct files that can 
    have DCO.
  - Leave the #_LIBC conditionals with minimal code.

* Stop sharing this code with gnulib, and own it.
  - Delete !#_LIBC code.
  - Simplify.
  - Use internal glibc interfaces
  - etc.

Does that answer your question?

-- 
Cheers,
Carlos.

Re: Update to glibc copyright assignment policy

[Siddhesh Poyarekar]

On 7/29/21 7:28 PM, Carlos O'Donell wrote:
> The code shared with gnulib carries with it an existing obligation
> to the gnulib community that we maintain the existing copyright
> protocol for those files to honour that obligation.
> 
> My suggestion is that we as a community in glibc need to decide,
> on a file-by-file basis what we are going to do. I'm open to other
> alternatives too, the following 2 steps are just my suggestion.
> 
> (1) Update https://sourceware.org/glibc/wiki/SharedSourceFiles with
>      the actual file status.
> 
> (2) Make a decision.
> 
> * Find a new way to share the code with minimal impact.
>    - Carve out glibc-related functions into distinct files that can
>      have DCO.
>    - Leave the #_LIBC conditionals with minimal code.
> 
> * Stop sharing this code with gnulib, and own it.
>    - Delete !#_LIBC code.
>    - Simplify.
>    - Use internal glibc interfaces
>    - etc.
> 
> Does that answer your question?
> 

Yes it does, thank you.  I agree that taking a call on a case by case 
basis seems like the right way to go about it.

Thanks,
Siddhesh

Re: Update to glibc copyright assignment policy

[Florian Weimer via Libc-alpha]

* Carlos O'Donell via Libc-alpha:

> On 7/29/21 6:25 AM, Siddhesh Poyarekar wrote:
>> On 7/29/21 1:20 AM, Carlos O'Donell via Libc-alpha wrote:
>>> branches. Code shared with other GNU packages via Gnulib will
>>> continue to require assignment to the FSF.
>> 
>> Does that mean we cannot touch the code shared with gnulib if we do
>> not assign copyright to the FSF?  Or does it mean that if/when that
>> happens, we will stop syncing those bits with gnulib?
>
> The code shared with gnulib carries with it an existing obligation
> to the gnulib community that we maintain the existing copyright
> protocol for those files to honour that obligation.
>
> My suggestion is that we as a community in glibc need to decide,
> on a file-by-file basis what we are going to do. I'm open to other
> alternatives too, the following 2 steps are just my suggestion.

I'm worried that this obligation means that we cannot use glibc-specific
facilities in code shared with gnulib.  For example, look at how the
scratch buffer mechanism landed in gnulib.  If we had DCO contributions
for that mechanism, that wouldn't be possible—and that facility started
out with the firm idea that it would never end up in gnulib.

Thanks,
Florian

Re: Update to glibc copyright assignment policy

[Paul Eggert]

On 7/29/21 7:21 AM, Florian Weimer via Libc-alpha wrote:
> I'm worried that this obligation means that we cannot use glibc-specific
> facilities in code shared with gnulib.

We'll just have to take those problems as they come. I'm not 
particularly worried about it. If it's an important facility that's 
portable, we can simply rewrite it for Gnulib and then share back as needed.

The main obstacles for sharing will likely continue to be technical, not 
political/legal.