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 
, 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 
> , 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

[PATCH] idx: new printf/scanf length modifier macro

[Paul Eggert]

* lib/idx.h (pIDX): New macro.
---
 ChangeLog | 5 +
 lib/idx.h | 4 
 2 files changed, 9 insertions(+)

diff --git a/ChangeLog b/ChangeLog
index b98de6bf6..4e8242ade 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,8 @@
+2021-06-14  Paul Eggert  
+
+   idx: new printf/scanf length modifier macro
+   * lib/idx.h (pIDX): New macro.
+
 2021-06-13  Bruno Haible  
 
Align 2011-11-26 patch to 2021-04-11 patch (regression from 2021-04-11).
diff --git a/lib/idx.h b/lib/idx.h
index 483587eab..28fd4ea72 100644
--- a/lib/idx.h
+++ b/lib/idx.h
@@ -107,6 +107,10 @@ typedef ptrdiff_t idx_t;
 /* IDX_MAX is the maximum value of an idx_t.  */
 #define IDX_MAX PTRDIFF_MAX
 
+/* A printf/scanf length modifier for idx_t.  For example, if i is an idx_t,
+   printf ("i = %"pIDX"d\n", i) outputs i's value.  */
+#define pIDX "t"
+
 /* So far no need has been found for an IDX_WIDTH macro.
Perhaps there should be another macro IDX_VALUE_BITS that does not
count the sign bit and is therefore one less than PTRDIFF_WIDTH.  */
-- 
2.30.2

Re: [PATCH] idx: new printf/scanf length modifier macro

[Bruno Haible]

> +/* A printf/scanf length modifier for idx_t.  For example, if i is an idx_t,
> +   printf ("i = %"pIDX"d\n", i) outputs i's value.  */
> +#define pIDX "t"

Note that this modifier is not supported in internationalized format strings.
gettext() supports only the modifier names from . [1]

Bruno

[1] https://www.gnu.org/software/gettext/manual/html_node/Preparing-Strings.html