bug-gnulib@gnu.org mirror (unofficial)
 help / color / mirror / Atom feed
From: Paul Eggert <eggert@cs.ucla.edu>
To: Gnulib bugs <bug-gnulib@gnu.org>
Subject: Seeking input from developers: glibc copyright assignment policy.
Date: Mon, 14 Jun 2021 13:39:26 -0700	[thread overview]
Message-ID: <9b5fff12-c16f-799f-6178-000b2e667d24@cs.ucla.edu> (raw)

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/


             reply	other threads:[~2021-06-14 20:39 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-06-14 20:39 Paul Eggert [this message]
2021-06-14 22:46 ` Seeking input from developers: glibc copyright assignment policy Bruno Haible
2021-06-15 12:03 ` Eric Blake
2021-06-15 16:32   ` Paul Smith
2021-06-15 17:14     ` Bruno Haible
2021-06-16 11:31     ` Eli Zaretskii
2021-06-15 21:08   ` Pádraig Brady
2021-06-16 13:10     ` Paul Smith
2021-06-16 11:47 ` Dmitry V. Levin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://lists.gnu.org/mailman/listinfo/bug-gnulib

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=9b5fff12-c16f-799f-6178-000b2e667d24@cs.ucla.edu \
    --to=eggert@cs.ucla.edu \
    --cc=bug-gnulib@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).