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/
next 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).