* Re: Seeking input from developers: glibc copyright assignment policy.
2021-06-14 18:52 Seeking input from developers: glibc copyright assignment policy Carlos O'Donell
@ 2021-06-14 19:08 ` Rich Felker
2021-06-14 19:25 ` Khem Raj
2021-06-14 20:05 ` Florian Weimer
` (11 subsequent siblings)
12 siblings, 1 reply; 86+ messages in thread
From: Rich Felker @ 2021-06-14 19:08 UTC (permalink / raw)
To: Carlos O'Donell
Cc: libc-alpha, Jakub Jelinek, Joseph S. Myers, Maxim Kuvyrkov
On Mon, Jun 14, 2021 at 02:52:03PM -0400, Carlos O'Donell via Libc-alpha wrote:
> 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.
I am very much in favor of removing the assignment requirement. I do
not, and have never, had an assignment in place (it's a running joke
that my patch contributions have been all-minus-signs) but given
recent behavior by the FSF board, I am completely unwilling to assign
copyright to them in the future, so not making this change may affect
my ability to contribute.
Rich
^ permalink raw reply [flat|nested] 86+ messages in thread
* Re: Seeking input from developers: glibc copyright assignment policy.
2021-06-14 19:08 ` Rich Felker
@ 2021-06-14 19:25 ` Khem Raj
0 siblings, 0 replies; 86+ messages in thread
From: Khem Raj @ 2021-06-14 19:25 UTC (permalink / raw)
To: Rich Felker
Cc: Carlos O'Donell, Jakub Jelinek, libc-alpha, Joseph S. Myers,
Maxim Kuvyrkov
On Mon, Jun 14, 2021 at 12:08 PM Rich Felker <dalias@libc.org> wrote:
>
> On Mon, Jun 14, 2021 at 02:52:03PM -0400, Carlos O'Donell via Libc-alpha wrote:
> > 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.
>
> I am very much in favor of removing the assignment requirement.
+1. adding an option to accept patches with DCO would greatly
simplify this for new/occasional
contributors
> not, and have never, had an assignment in place (it's a running joke
> that my patch contributions have been all-minus-signs) but given
> recent behavior by the FSF board, I am completely unwilling to assign
> copyright to them in the future, so not making this change may affect
> my ability to contribute.
+1
>
> Rich
^ permalink raw reply [flat|nested] 86+ messages in thread
* Re: Seeking input from developers: glibc copyright assignment policy.
2021-06-14 18:52 Seeking input from developers: glibc copyright assignment policy Carlos O'Donell
2021-06-14 19:08 ` Rich Felker
@ 2021-06-14 20:05 ` Florian Weimer
2021-06-14 20:22 ` Matt Turner
2021-06-14 21:16 ` Paul Eggert
2021-06-14 20:18 ` Matt Turner
` (10 subsequent siblings)
12 siblings, 2 replies; 86+ messages in thread
From: Florian Weimer @ 2021-06-14 20:05 UTC (permalink / raw)
To: Carlos O'Donell via Libc-alpha
Cc: Carlos O'Donell, Jakub Jelinek, Joseph S. Myers, Maxim Kuvyrkov
* Carlos O'Donell via Libc-alpha:
> 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.
Given that we already have hundreds of commits with Signed-off-by:, and
glibc has accepted contributions written for glibc under different,
LGLPv2-compatible licenses without copyright assignment in the past,
this is a welcome clarification.
Will gnulib adopt a similar policy?
Thanks,
Florian
^ permalink raw reply [flat|nested] 86+ messages in thread
* Re: Seeking input from developers: glibc copyright assignment policy.
2021-06-14 20:05 ` Florian Weimer
@ 2021-06-14 20:22 ` Matt Turner
2021-06-15 20:28 ` Carlos O'Donell
2021-06-14 21:16 ` Paul Eggert
1 sibling, 1 reply; 86+ messages in thread
From: Matt Turner @ 2021-06-14 20:22 UTC (permalink / raw)
To: Florian Weimer
Cc: Carlos O'Donell via Libc-alpha, Jakub Jelinek,
Joseph S. Myers, Maxim Kuvyrkov
On Mon, Jun 14, 2021 at 1:06 PM Florian Weimer via Libc-alpha
<libc-alpha@sourceware.org> wrote:
> Given that we already have hundreds of commits with Signed-off-by:, and
> glibc has accepted contributions written for glibc under different,
> LGLPv2-compatible licenses without copyright assignment in the past,
> this is a welcome clarification.
FWIW, this is why I asked and convinced some Mesa developers to stop
appending S-o-b tags to their commits: without an assigned meaning,
all it does is complicate matters when a project does adopt a DCO and
indicates its acceptance through S-o-b tags.
^ permalink raw reply [flat|nested] 86+ messages in thread
* Re: Seeking input from developers: glibc copyright assignment policy.
2021-06-14 20:22 ` Matt Turner
@ 2021-06-15 20:28 ` Carlos O'Donell
0 siblings, 0 replies; 86+ messages in thread
From: Carlos O'Donell @ 2021-06-15 20:28 UTC (permalink / raw)
To: Matt Turner, Florian Weimer
Cc: Jakub Jelinek, Carlos O'Donell via Libc-alpha,
Joseph S. Myers, Maxim Kuvyrkov
On 6/14/21 4:22 PM, Matt Turner via Libc-alpha wrote:
> On Mon, Jun 14, 2021 at 1:06 PM Florian Weimer via Libc-alpha
> <libc-alpha@sourceware.org> wrote:
>> Given that we already have hundreds of commits with Signed-off-by:, and
>> glibc has accepted contributions written for glibc under different,
>> LGLPv2-compatible licenses without copyright assignment in the past,
>> this is a welcome clarification.
>
> FWIW, this is why I asked and convinced some Mesa developers to stop
> appending S-o-b tags to their commits: without an assigned meaning,
> all it does is complicate matters when a project does adopt a DCO and
> indicates its acceptance through S-o-b tags.
Thank you for that feedback.
I agree that Signed-off-by: needs to have a defined meaning for there
to be a benefit created for the project.
--
Cheers,
Carlos.
^ permalink raw reply [flat|nested] 86+ messages in thread
* Re: Seeking input from developers: glibc copyright assignment policy.
2021-06-14 20:05 ` Florian Weimer
2021-06-14 20:22 ` Matt Turner
@ 2021-06-14 21:16 ` Paul Eggert
1 sibling, 0 replies; 86+ messages in thread
From: Paul Eggert @ 2021-06-14 21:16 UTC (permalink / raw)
To: Florian Weimer, Carlos O'Donell via Libc-alpha
Cc: Jakub Jelinek, Joseph S. Myers, Maxim Kuvyrkov
On 6/14/21 1:05 PM, Florian Weimer via Libc-alpha wrote:
> Given that we already have hundreds of commits with Signed-off-by:, and
> glibc has accepted contributions written for glibc under different,
> LGLPv2-compatible licenses without copyright assignment in the past,
> this is a welcome clarification.
>
> Will gnulib adopt a similar policy?
I would expect so. In many cases we simply copy from glibc, so we're
using glibc's policy there. For non-glibc files, Gnulib could stick with
the current policy, or move to glibc's policy.
Today I raised this issue on bug-gnulib to solicit Gnulib developers'
opinions <https://lists.gnu.org/r/bug-gnulib/2021-06/msg00079.html>.
^ permalink raw reply [flat|nested] 86+ messages in thread
* Re: Seeking input from developers: glibc copyright assignment policy.
2021-06-14 18:52 Seeking input from developers: glibc copyright assignment policy Carlos O'Donell
2021-06-14 19:08 ` Rich Felker
2021-06-14 20:05 ` Florian Weimer
@ 2021-06-14 20:18 ` Matt Turner
2021-06-14 20:22 ` Adhemerval Zanella
` (9 subsequent siblings)
12 siblings, 0 replies; 86+ messages in thread
From: Matt Turner @ 2021-06-14 20:18 UTC (permalink / raw)
To: Carlos O'Donell
Cc: libc-alpha, Jakub Jelinek, Joseph S. Myers, Maxim Kuvyrkov
On Mon, Jun 14, 2021 at 11:53 AM Carlos O'Donell via Libc-alpha
<libc-alpha@sourceware.org> wrote:
>
> 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.
Yes, please!
To give a concrete example of what a barrier this can be to contributors:
When I was in graduate school and contracting for OLPC, I wanted to
contribute a fix to GCC [1]. I was asked to complete the copyright
assignment paperwork and disclosed that I was a student in university.
That necessitated the FSF paperwork being approved by my university...
Research universities often have technology-transfer rules, designed
around handling inventions created by professors and research
assistants. Despite not doing research for the university, not working
on GCC for the university, not doing the work with anyone from the
university, and not doing the work with any property from the
university, the university required me to fill out paperwork
describing the "invention" and provide information on how they might
"market it".
A process which began in October finally concluded in April, the month
before I graduated. Not coincidentally, someone in the tech-transfer
office asked me if I could simply wait until after I graduated to
contribute...
I can imagine most people would simply not contribute if they knew
they'd have to go through this (or neglect to mention to the FSF that
they're a university student, as I would do if I had known).
None of this is the fault of the copyright assignment policy per se,
but it does demonstrate how it's not as simple as signing a piece of
paper.
[1] I believe it was
https://patchwork.ozlabs.org/project/gcc/patch/CAEdQ38ECXJahf8sp8b7Yq5NgOQBh9MQ7s3LxfSmZJhJva-UfDg@mail.gmail.com/
^ permalink raw reply [flat|nested] 86+ messages in thread
* Re: Seeking input from developers: glibc copyright assignment policy.
2021-06-14 18:52 Seeking input from developers: glibc copyright assignment policy Carlos O'Donell
` (2 preceding siblings ...)
2021-06-14 20:18 ` Matt Turner
@ 2021-06-14 20:22 ` Adhemerval Zanella
2021-06-15 2:48 ` Siddhesh Poyarekar
` (8 subsequent siblings)
12 siblings, 0 replies; 86+ messages in thread
From: Adhemerval Zanella @ 2021-06-14 20:22 UTC (permalink / raw)
To: libc-alpha
On 14/06/2021 15:52, Carlos O'Donell via Libc-alpha wrote:
> 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.
From the gcc maillist thread [1], it seemed that the vast majority if not
all gcc developers were in favor of the change. I also agree this is the
way forward to help improve contributions and the project engagement.
[1] https://gcc.gnu.org/pipermail/gcc/2021-June/236182.html
^ permalink raw reply [flat|nested] 86+ messages in thread
* Re: Seeking input from developers: glibc copyright assignment policy.
2021-06-14 18:52 Seeking input from developers: glibc copyright assignment policy Carlos O'Donell
` (3 preceding siblings ...)
2021-06-14 20:22 ` Adhemerval Zanella
@ 2021-06-15 2:48 ` Siddhesh Poyarekar
2021-06-15 3:18 ` DJ Delorie
` (7 subsequent siblings)
12 siblings, 0 replies; 86+ messages in thread
From: Siddhesh Poyarekar @ 2021-06-15 2:48 UTC (permalink / raw)
To: Carlos O'Donell, libc-alpha
Cc: Jakub Jelinek, Joseph S. Myers, Maxim Kuvyrkov
On 6/15/21 12:22 AM, Carlos O'Donell via Libc-alpha wrote:
> 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.
As someone who has nagged about this at practically every Cauldron I've
attended, I think this is a positive change and I fully endorse it. The
copyright assignment step has been a pretty significant hurdle for me in
the past when I've tried to get more students in India involved in the
GNU toolchain.
Siddhesh
^ permalink raw reply [flat|nested] 86+ messages in thread
* Re: Seeking input from developers: glibc copyright assignment policy.
2021-06-14 18:52 Seeking input from developers: glibc copyright assignment policy Carlos O'Donell
` (4 preceding siblings ...)
2021-06-15 2:48 ` Siddhesh Poyarekar
@ 2021-06-15 3:18 ` DJ Delorie
2021-06-15 17:41 ` Paul Eggert
2021-06-15 3:39 ` Daniel Black
` (6 subsequent siblings)
12 siblings, 1 reply; 86+ messages in thread
From: DJ Delorie @ 2021-06-15 3:18 UTC (permalink / raw)
To: Carlos O'Donell; +Cc: libc-alpha
"Carlos O'Donell via Libc-alpha" <libc-alpha@sourceware.org> writes:
> 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.
I'm for this change, but it's my belief that the DCO will be treated
like a EULA - don't read it, just accept it. I will consider every
"Signed-off-by:" as a "I-don't-know-if-I-own-this:" admission. "I don't
need to check with legal, I just need to put this line in my email and
everything is OK."
However, the FSF assignment is the biggest roadblock to new
contributors, and I think that's a bigger potential problem than the
potential DCO problems.
> 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 paragraph was worded poorly. We will not be developing under any
later version, ever. We will distribute under terms that allow using
later versions' terms. The DCO means we will never change the version
of GPL we use, it's important to not blur that point.
^ permalink raw reply [flat|nested] 86+ messages in thread
* Re: Seeking input from developers: glibc copyright assignment policy.
2021-06-15 3:18 ` DJ Delorie
@ 2021-06-15 17:41 ` Paul Eggert
2021-06-15 18:43 ` DJ Delorie
0 siblings, 1 reply; 86+ messages in thread
From: Paul Eggert @ 2021-06-15 17:41 UTC (permalink / raw)
To: DJ Delorie, Carlos O'Donell; +Cc: libc-alpha
On 6/14/21 8:18 PM, DJ Delorie via Libc-alpha wrote:
> The DCO means we will never change the version
> of GPL we use
If the DCO really means that then it could be trouble, as copyright law
mutates and the LGPL clause that lets you redistribute under later
versions is an important escape hatch to deal with future changes to
copyright law.
But I don't understand why the DCO really means that; could you explain?
^ permalink raw reply [flat|nested] 86+ messages in thread
* Re: Seeking input from developers: glibc copyright assignment policy.
2021-06-15 17:41 ` Paul Eggert
@ 2021-06-15 18:43 ` DJ Delorie
2021-06-15 19:05 ` Paul Eggert
0 siblings, 1 reply; 86+ messages in thread
From: DJ Delorie @ 2021-06-15 18:43 UTC (permalink / raw)
To: Paul Eggert; +Cc: carlos, libc-alpha
Paul Eggert <eggert@cs.ucla.edu> writes:
> On 6/14/21 8:18 PM, DJ Delorie via Libc-alpha wrote:
>> The DCO means we will never change the version
>> of GPL we use
>
> If the DCO really means that then it could be trouble, as copyright law
> mutates and the LGPL clause that lets you redistribute under later
> versions is an important escape hatch to deal with future changes to
> copyright law.
>
> But I don't understand why the DCO really means that; could you explain?
If N people collectively own copyright, then all N need to agree in
order to change the licensing terms. The Linux kernel is stuck at GPL2
for this reason; they effectively can't get all the copyright owners to
agree to change it.
DCO means that N > 1 for glibc. The higher N is, the harder it is to
get agreements to change.
Note that the 'or later versions' clause does NOT let anyone arbitrarily
change the license! If $person takes a copy of glibc and distributes it
to $person2 under the terms of GPLv4, then $person2 still has the "GPLv3
or later" option; they obtain their license from the owners, not from
the intermediates, so how the intermediates choose to redistribute is -
from a license point of view - irrelevent.
So once our DCO count is high enough, glibc is stuck with "GPLv3 or
later". Folks (including us) will always have the option of following a
later GPL, but they will also always have the option of following GPLv3.
Of course, the usual IANAL.
^ permalink raw reply [flat|nested] 86+ messages in thread
* Re: Seeking input from developers: glibc copyright assignment policy.
2021-06-15 18:43 ` DJ Delorie
@ 2021-06-15 19:05 ` Paul Eggert
2021-06-15 19:12 ` DJ Delorie
0 siblings, 1 reply; 86+ messages in thread
From: Paul Eggert @ 2021-06-15 19:05 UTC (permalink / raw)
To: DJ Delorie; +Cc: carlos, libc-alpha
On 6/15/21 11:43 AM, DJ Delorie wrote:
> The Linux kernel is stuck at GPL2
> for this reason; they effectively can't get all the copyright owners to
> agree to change it.
That's because the Linux code is distributed under its own terms, which
is mostly LGPL2-only. That is, they've stuck at LGPL2 on purpose.
In contrast, the Glibc library code is explicitly LGPL2.1+ (with
emphasis on the "+"). DCO'd contributions to GLibc would be under
Glibc's terms, not Linux's. Since Glibc's terms explicitly allow it to
be redistributed under later versions of the LGPL, a future Glibc
release could use LGPL4 (should a version 4 ever come out).
You're right that if Glibc switches to a future LGPL4 then Glibc's DCO'd
parts (if unmodified) could still be redistributed separately under
LGPLv2.1, just as any other part of glibc (if unmodified) would continue
to be redistributable under LGPLv2.1. However, the new glibc library
code as a whole could simply move to LGPL4 without any licensing issues
presented by the DCO components.
Currently this issue is no big deal, because for various reasons Glibc
library code is stuck on LGPL2.1 even though LGPL3.0 came out in 2007.
But if copyright law changes and an LGPL 4 becomes necessary, the
distinction could become important.
> Of course, the usual IANAL.
Oh likewise, likewise.
^ permalink raw reply [flat|nested] 86+ messages in thread
* Re: Seeking input from developers: glibc copyright assignment policy.
2021-06-15 19:05 ` Paul Eggert
@ 2021-06-15 19:12 ` DJ Delorie
2021-06-15 19:35 ` Paul Eggert
0 siblings, 1 reply; 86+ messages in thread
From: DJ Delorie @ 2021-06-15 19:12 UTC (permalink / raw)
To: Paul Eggert; +Cc: carlos, libc-alpha
Paul Eggert <eggert@cs.ucla.edu> writes:
> In contrast, the Glibc library code is explicitly LGPL2.1+ (with
> emphasis on the "+"). DCO'd contributions to GLibc would be under
> Glibc's terms, not Linux's. Since Glibc's terms explicitly allow it to
> be redistributed under later versions of the LGPL,
So far so good.
> a future Glibc release could use LGPL4 (should a version 4 ever come
> out).
Sorta. A future glibc could distribute under the terms of LGPL4+, but a
future glibc could NOT change the license to "LGPL4+". I.e. if LGPL2.1
had a problem, we could not fix the problem by preventing LGPL2.1 from
being used. *We* could use LGPL4, but we can't take away someone else's
right to use LGPL2.1. Only the copyright owner(s) can do that.
^ permalink raw reply [flat|nested] 86+ messages in thread
* Re: Seeking input from developers: glibc copyright assignment policy.
2021-06-15 19:12 ` DJ Delorie
@ 2021-06-15 19:35 ` Paul Eggert
2021-06-15 19:42 ` DJ Delorie
` (2 more replies)
0 siblings, 3 replies; 86+ messages in thread
From: Paul Eggert @ 2021-06-15 19:35 UTC (permalink / raw)
To: DJ Delorie; +Cc: carlos, libc-alpha
On 6/15/21 12:12 PM, DJ Delorie wrote:
> A future glibc could distribute under the terms of LGPL4+, but a
> future glibc could NOT change the license to "LGPL4+".
So, are you saying that in string/strcpy.c we could not change the "2.1"
to 3 in the following comment:
The GNU C Library is free software; you can redistribute it and/or
modify it under the terms of the GNU Lesser General Public
License as published by the Free Software Foundation; either
version 2.1 of the License, or (at your option) any later version.
and redistribute the result, assuming strcpy.c has some DCO'ed code?
We've routinely been doing such replacements for years in other Gnu
code. Gnulib even automates the practice.
If true, it's a significant argument against going with DCO'ed code.
Certainly we couldn't accept DCO'ed material in any Glibc code shared
with Gnulib, as Gnulib code is shared among many GNU projects that don't
do DCO and do such rewriting. And even if we ignore Gnulib, this could
be a real problem if copyright law were to change in a way that
adversely affects free-software principles, so that we'd really need an
LGPL 4.
Have the Red Hat lawyers looked into this issue specifically?
^ permalink raw reply [flat|nested] 86+ messages in thread
* Re: Seeking input from developers: glibc copyright assignment policy.
2021-06-15 19:35 ` Paul Eggert
@ 2021-06-15 19:42 ` DJ Delorie
2021-06-15 20:08 ` Carlos O'Donell
2021-07-02 22:33 ` Carlos O'Donell
2 siblings, 0 replies; 86+ messages in thread
From: DJ Delorie @ 2021-06-15 19:42 UTC (permalink / raw)
To: Paul Eggert; +Cc: carlos, libc-alpha
Paul Eggert <eggert@cs.ucla.edu> writes:
> On 6/15/21 12:12 PM, DJ Delorie wrote:
>> A future glibc could distribute under the terms of LGPL4+, but a
>> future glibc could NOT change the license to "LGPL4+".
>
> So, are you saying that in string/strcpy.c we could not change the "2.1"
> to 3 in the following comment:
Only of all the copyright owners of that file agreed. That is, the FSF
plus any DCO'd patches' owners.
> If true, it's a significant argument against going with DCO'ed code.
Yes, that is a key thing here. Whether that's a pro or a con is up to
you.
pro: A future EvilFSF can't make the code non-free.
con: Bugs in GPL can't be fixed.
^ permalink raw reply [flat|nested] 86+ messages in thread
* Re: Seeking input from developers: glibc copyright assignment policy.
2021-06-15 19:35 ` Paul Eggert
2021-06-15 19:42 ` DJ Delorie
@ 2021-06-15 20:08 ` Carlos O'Donell
2021-07-02 22:33 ` Carlos O'Donell
2 siblings, 0 replies; 86+ messages in thread
From: Carlos O'Donell @ 2021-06-15 20:08 UTC (permalink / raw)
To: Paul Eggert, DJ Delorie; +Cc: libc-alpha
On 6/15/21 3:35 PM, Paul Eggert wrote:
> On 6/15/21 12:12 PM, DJ Delorie wrote:
>> A future glibc could distribute under the terms of LGPL4+, but a
>> future glibc could NOT change the license to "LGPL4+".
>
> So, are you saying that in string/strcpy.c we could not change the
> "2.1" to 3 in the following comment:
This changes the license of the code.
> The GNU C Library is free software; you can redistribute it and/or
> modify it under the terms of the GNU Lesser General Public License as
> published by the Free Software Foundation; either version 2.1 of the
> License, or (at your option) any later version.
>
> and redistribute the result, assuming strcpy.c has some DCO'ed code?
> We've routinely been doing such replacements for years in other Gnu
> code. Gnulib even automates the practice.
You should contact legal counsel to determine if you have the right
to relicense that code.
> If true, it's a significant argument against going with DCO'ed code.
Why is it a significant argument against DCO?
Yes, does make it more difficult to relicense the project (it is not
impossible), other than to a later version of the GPL. We are a mature
collection of projects and our users and developers depend on the
project to retain the existing license for long term planning. Users
and developers contribute to our projects because of our values and
principles and those are tied to the license that we are using.
Telling our users and developers that we will never change the license
has value.
> Certainly we couldn't accept DCO'ed material in any Glibc code shared
> with Gnulib, as Gnulib code is shared among many GNU projects that
> don't do DCO and do such rewriting. And even if we ignore Gnulib,
> this could be a real problem if copyright law were to change in a way
> that adversely affects free-software principles, so that we'd really
> need an LGPL 4.
Can you quantify this risk of not being able to move to LGPLv4?
Can you quantify the risk of using DCO?
What license would we change to?
Does the LGPLv4 exist today?
What do our users expect?
The problem is that risk quantification is difficult and neither side
has a clear advantage against all costs and benefits.
The clearest advantage to DCO is the future growth and vibrancy of the
GNU Toolchain. The GNU Toolchain deserves the brightest future we can
provide.
In practice glibc contains a fair bit of code unassigned to the FSF for
which the license cannot be easily changed without legal discussions
(Intel, IBM, Sun Microsystems, SGI, Oracle, Carnegie Mellon University,
DEC, ISC, University of California, University of Cambridge, ORNL,
Unicode Consortium, and various authors). And some companies no longer
exist.
There are approximately 704 files that have copyright owners other than
the FSF, and if the FSF does have copyright ownership by other contractual
means then that isn't clear and subject to complex legal discussions for
relicensing.
The reality of the GNU Toolchain copyright ownership is different
from expectation.
The DCO is in keeping with the reality of the GNU Toolchain and opens
up opportunities for further contributions.
> Have the Red Hat lawyers looked into this issue specifically?
This is a known issue with DCO.
If there is a specific question you have then we can start a thread
to discuss the issue.
--
Cheers,
Carlos.
^ permalink raw reply [flat|nested] 86+ messages in thread
* Re: Seeking input from developers: glibc copyright assignment policy.
2021-06-15 19:35 ` Paul Eggert
2021-06-15 19:42 ` DJ Delorie
2021-06-15 20:08 ` Carlos O'Donell
@ 2021-07-02 22:33 ` Carlos O'Donell
2021-07-03 1:59 ` Paul Eggert
2021-07-03 3:24 ` Bruno Haible
2 siblings, 2 replies; 86+ messages in thread
From: Carlos O'Donell @ 2021-07-02 22:33 UTC (permalink / raw)
To: Paul Eggert, DJ Delorie, Dmitry V. Levin, Bruno Haible; +Cc: libc-alpha
On 6/15/21 3:35 PM, Paul Eggert wrote:
> If true, it's a significant argument against going with DCO'ed code.
> Certainly we couldn't accept DCO'ed material in any Glibc code shared
> with Gnulib, as Gnulib code is shared among many GNU projects that
> don't do DCO and do such rewriting.
gnulib already accepts such code.
gnulib has been including non-FSF copyrighted material in various
modules (that include the files below) for a long time.
gnulib could add markup to the modules to indicate if they contain
non-FSF copyrighted material, and then allow the including projects
to decide if this is acceptable to them or not?
The following files in gnulib are not copyright the FSF:
lib/acosl.c:
Copyright (C) 1993 by Sun Microsystems, Inc. All rights reserved.
lib/asinl.c:
Copyright (C) 1993 by Sun Microsystems, Inc. All rights reserved.
lib/cosl.c:
Copyright (C) 1993 by Sun Microsystems, Inc. All rights reserved.
lib/sinl.c:
Copyright (C) 1993 by Sun Microsystems, Inc. All rights reserved.
lib/tanl.c:
Copyright (C) 1993 by Sun Microsystems, Inc. All rights reserved.
lib/trigl.c:
Copyright (C) 1993 by Sun Microsystems, Inc. All rights reserved.
lib/atanl.c:
Copyright 2001 by Stephen L. Moshier <moshier@na-net.ornl.gov>
lib/cbrtl.c:
Copyright 1984, 1991 by Stephen L. Moshier
lib/logl.c:
Copyright 2001 by Stephen L. Moshier <moshier@na-net.ornl.gov>
lib/filevercmp.c:
lib/filevercmp.h:
Copyright (C) 1995 Ian Jackson <iwj10@cus.cam.ac.uk>
Copyright (C) 2001 Anthony Towns <aj@azure.humbug.org.au>
lib/fts.c:
Copyright (c) 1990, 1993, 1994 The Regents of the University of California. All rights reserved.
lib/fts_.h:
Copyright (c) 1989, 1993 The Regents of the University of California. All rights reserved.
lib/inet_ntop.c:
Copyright (c) 1996-1999 by Internet Software Consortium.
lib/inet_pton.c:
Copyright (c) 1996,1999 by Internet Software Consortium.
lib/random.c:
lib/random_r.c:
Copyright (C) 1983 Regents of the University of California. All rights reserved.
lib/sigsegv.c:
Copyright (C) 2018 Nylon Chen <nylon7@andestech.com>
lib/stackvma.c:
lib/stackvma.h:
Copyright (C) 2003-2006 Paolo Bonzini <bonzini@gnu.org>
--
Cheers,
Carlos.
^ permalink raw reply [flat|nested] 86+ messages in thread
* Re: Seeking input from developers: glibc copyright assignment policy.
2021-07-02 22:33 ` Carlos O'Donell
@ 2021-07-03 1:59 ` Paul Eggert
2021-07-04 0:40 ` Paul Eggert
2021-07-05 20:37 ` Joseph Myers
2021-07-03 3:24 ` Bruno Haible
1 sibling, 2 replies; 86+ messages in thread
From: Paul Eggert @ 2021-07-03 1:59 UTC (permalink / raw)
To: Carlos O'Donell, DJ Delorie, Dmitry V. Levin, Bruno Haible; +Cc: libc-alpha
On 7/2/21 3:33 PM, Carlos O'Donell wrote:
> gnulib has been including non-FSF copyrighted material in various
> modules (that include the files below) for a long time.
If gnulib-tool modifies any of those non-FSF copyright notices, then
that's a bug that should be fixed. It doesn't modify the first one, so
we should be OK there. (I didn't check the others.)
This raises another issue. What will be the glibc policy about putting
copyright notices on files containing DCOed material? Will there be a
separate copyright notice for each contributor? Linux doesn't do that -
which is too sloppy for glibc, surely. I don't know what GCC plans to do.
^ permalink raw reply [flat|nested] 86+ messages in thread
* Re: Seeking input from developers: glibc copyright assignment policy.
2021-07-03 1:59 ` Paul Eggert
@ 2021-07-04 0:40 ` Paul Eggert
2021-07-04 11:55 ` Florian Weimer
2021-07-05 20:37 ` Joseph Myers
1 sibling, 1 reply; 86+ messages in thread
From: Paul Eggert @ 2021-07-04 0:40 UTC (permalink / raw)
To: Carlos O'Donell, DJ Delorie, Dmitry V. Levin, Bruno Haible; +Cc: libc-alpha
On 7/2/21 6:59 PM, Paul Eggert wrote:
> If gnulib-tool modifies any of those non-FSF copyright notices, then
> that's a bug that should be fixed.
I've been reminded that gnulib-tool no longer modifies copyright
notices, so there's no bug here.
> What will be the glibc policy about putting
> copyright notices on files containing DCOed material? Will there be a
> separate copyright notice for each contributor? Linux doesn't do that -
> which is too sloppy for glibc, surely. I don't know what GCC plans to do.
Following up on this, I propose that if DCO'ed contributions are
accepted for a file, the file should contain a proper copyright notice
listing the authors and the range of years that each contributed. E.g.,
the start of the file would look like this:
/* Word-wrapping and line-truncating streams.
Copyright (C) 1997-2022 Free Software Foundation, Inc.
Copyright (C) 2021-2022 Alejandro Davis.
Copyright (C) 2022 Sharon Carter, Debra Lindsey.
This file is part of the GNU C Library.
The GNU C Library is free software; you can redistribute it ...
This issue shouldn't arise for Glibc files shared with Gnulib, as
they'll still follow the current policy.
^ permalink raw reply [flat|nested] 86+ messages in thread
* Re: Seeking input from developers: glibc copyright assignment policy.
2021-07-04 0:40 ` Paul Eggert
@ 2021-07-04 11:55 ` Florian Weimer
2021-07-04 18:32 ` Paul Eggert
2021-07-05 5:00 ` Carlos O'Donell
0 siblings, 2 replies; 86+ messages in thread
From: Florian Weimer @ 2021-07-04 11:55 UTC (permalink / raw)
To: Paul Eggert
Cc: Carlos O'Donell, DJ Delorie, Dmitry V. Levin, Bruno Haible,
libc-alpha
* Paul Eggert:
> Following up on this, I propose that if DCO'ed contributions are
> accepted for a file, the file should contain a proper copyright notice
> listing the authors and the range of years that each
> contributed. E.g., the start of the file would look like this:
>
> /* Word-wrapping and line-truncating streams.
> Copyright (C) 1997-2022 Free Software Foundation, Inc.
> Copyright (C) 2021-2022 Alejandro Davis.
> Copyright (C) 2022 Sharon Carter, Debra Lindsey.
> This file is part of the GNU C Library.
>
> The GNU C Library is free software; you can redistribute it ...
>
> This issue shouldn't arise for Glibc files shared with Gnulib, as
> they'll still follow the current policy.
I would prefer something along the lines “Copyright The glibc
Contributors”. No year or year range, no individual names. Listing
years is apparently not legally required, and naming individual authors
is also optional. See:
Copyright Notices in Open Source Software Projects
<https://www.linuxfoundation.org/en/blog/copyright-notices-in-open-source-software-projects/>
Today, we have some trouble removing “Contributed by” lines in cases
where they may be no longer applicable. I don't think we should create
more problems like that.
Thanks,
Florian
^ permalink raw reply [flat|nested] 86+ messages in thread
* Re: Seeking input from developers: glibc copyright assignment policy.
2021-07-04 11:55 ` Florian Weimer
@ 2021-07-04 18:32 ` Paul Eggert
2021-07-04 23:25 ` Bradley M. Kuhn
2021-07-05 5:28 ` Carlos O'Donell
2021-07-05 5:00 ` Carlos O'Donell
1 sibling, 2 replies; 86+ messages in thread
From: Paul Eggert @ 2021-07-04 18:32 UTC (permalink / raw)
To: Florian Weimer
Cc: Carlos O'Donell, DJ Delorie, Dmitry V. Levin, Bruno Haible,
libc-alpha
On 7/4/21 4:55 AM, Florian Weimer wrote:
> I would prefer something along the lines “Copyright The glibc
> Contributors”. No year or year range, no individual names. Listing
> years is apparently not legally required
That's an oversimplification of copyright law. In the US although no
copyright notice is legally *required* to hold a copyright, there are
legal *benefits* to having a proper copyright notice, and the FSF surely
wants those benefits. So at the very least the FSF must be specifically
listed in the copyright notice of any file containing material
copyrighted by the FSF.
Whether non-FSF copyright owners want to forgo those benefits, is up to
them. The DCO Sign-off form I've seen doesn't mention this issue, so
it'd be safer (and more polite) to list each copyright owner.
A proper copyright notice consists of (1) "©" or "Copyright" or "Copr.",
(2) the year(s) of first publication of the work, and (3) the name(s) of
the copyright owner(s). For more details, please see Chapter 2200
"Notice of Copyright" of the Compendium of US Copyright Office
Practices, 3rd edition (2021)
<https://www.copyright.gov/comp3/chap2200/ch2200-notice.pdf>.
To software developers this may all sound like a bunch of bureaucratic
paperwork, but I can assure you that to a copyright attorney this stuff
can be a big deal.
^ permalink raw reply [flat|nested] 86+ messages in thread
* Re: Seeking input from developers: glibc copyright assignment policy.
2021-07-04 18:32 ` Paul Eggert
@ 2021-07-04 23:25 ` Bradley M. Kuhn
2021-07-05 15:26 ` Christoph Hellwig
2021-07-05 5:28 ` Carlos O'Donell
1 sibling, 1 reply; 86+ messages in thread
From: Bradley M. Kuhn @ 2021-07-04 23:25 UTC (permalink / raw)
To: libc-alpha
> On 7/4/21 4:55 AM, Florian Weimer wrote:
> > I would prefer something along the lines “Copyright The glibc
> > Contributors”.
IANAL, but my own experience and work with GPL enforcement and lots of
copyright issues, and information I've received from copyright attorneys over
the years have convinced me it's a big mistake to create a copyright notice
that lists as the legal entity as something that has no legal standing. So,
unless you plan to form an organization called “the glibc Contributors”, I
advise against that notice.
What I recommend, though, if glibc is definitely going to a multi-copyright
held work, that you move copyright inventory to a single top-level file
instead of keeping it file-by-file.
In my years of examining FOSS code, I regularly find that developers,
particularly when working under the DCO, do a terrible job at keeping
file-by-file copyright inventory up-to-date. The Linux project has
disturbingly taken to *removing* all such file-by-file copyright notices from
the source tree entirely, which is an over-correction and just as bad a
mistake in the other direction. I just think file-by-file copyright notice
inventory has become so inaccurate in multi-copyright-held works that it
essential becomes a fiction: the copyright notice ends up being just the
first few people who worked on the file in question, and later contributors
simply forget to include an update of the copyright notices in the files.
As others have pointed out, copyright notices aren't mandatory under
copyright law to get move of the benefits. Paul Eggert is quite correct that
there are some *minor* legal benefits in some countries to keep copyright
notices in place. (Some folks do argue that those benefits are so strong
that it's imperative to keep copyright notices accurate on a file-by-file
basis; but I disagree with that position). The fact is, storing copyrighted
materials in separate files on a computer is purely a technical convenience,
as copyright law doesn't generally think in terms of “what file it was in”
but rather “what is the work in question”. (Licenses like the MPL do have
certain requirements that are file-based, but the LGPL and GPL doesn't have
these kinds of requirements.)
Thus, my usual recommendations to projects is to change the file-level notices
to something like:
/* License: LGPLv2-or-later ; copyright and license notices kept in file
** COPYRIGHT at the top level of this source tree, and available at <URL>
** if you receive this file separated from the entire source tree
*/
and then move all the file-by-file notices, with the long text from the LGPL
about the license details, plus the copyright notices, together into that
*one* file called COPYRIGHT at the top-level, and encourage contributors to
update that file if they want a copyright notice added.
Again, IANAL and TINLA. I recommend that the Glibc developers talk to
multiple copyright attorneys about these issues before making a change, and
copyright attorneys do disagree about some of these things in my experience.
The issues you're going to face moving to a fully multi-copyright-held work
are going to be many; I urge you to sort all this out before dropping
copyright assignment.
* * *
Finally, since I'm posting my first email here after the feedback deadline,
I'd like to inquire about what the leaders of the glibc project thought about
all the feedback received and if the plans have been made any more detailed
based on the feedback received — particularly with regard to what, if
anything, the project is going to do to figure out who the real copyright
holders are of various contributors once opt-outs of assignment begin.
--
Bradley M. Kuhn - he/him
Policy Fellow & Hacker-in-Residence at Software Freedom Conservancy
========================================================================
Become a Conservancy Supporter today: https://sfconservancy.org/supporter
^ permalink raw reply [flat|nested] 86+ messages in thread
* Re: Seeking input from developers: glibc copyright assignment policy.
2021-07-04 23:25 ` Bradley M. Kuhn
@ 2021-07-05 15:26 ` Christoph Hellwig
2021-07-06 18:02 ` Bradley M. Kuhn
0 siblings, 1 reply; 86+ messages in thread
From: Christoph Hellwig @ 2021-07-05 15:26 UTC (permalink / raw)
To: Bradley M. Kuhn; +Cc: libc-alpha
On Sun, Jul 04, 2021 at 04:25:16PM -0700, Bradley M. Kuhn wrote:
> In my years of examining FOSS code, I regularly find that developers,
> particularly when working under the DCO, do a terrible job at keeping
> file-by-file copyright inventory up-to-date. The Linux project has
> disturbingly taken to *removing* all such file-by-file copyright notices from
> the source tree entirely, which is an over-correction and just as bad a
> mistake in the other direction.
That is factually incorrect. per-file copyright notices are not removed
and in fact added by many (although not all contributors). Updates are
often rather sloppy, though.
^ permalink raw reply [flat|nested] 86+ messages in thread
* Re: Seeking input from developers: glibc copyright assignment policy.
2021-07-05 15:26 ` Christoph Hellwig
@ 2021-07-06 18:02 ` Bradley M. Kuhn
0 siblings, 0 replies; 86+ messages in thread
From: Bradley M. Kuhn @ 2021-07-06 18:02 UTC (permalink / raw)
To: libc-alpha
> On Sun, Jul 04, 2021 at 04:25:16PM -0700, Bradley M. Kuhn wrote:
> > In my years of examining FOSS code, I regularly find that developers,
> > particularly when working under the DCO, do a terrible job at keeping
> > file-by-file copyright inventory up-to-date.
^^^^^^^^^^^^
Christoph Hellwig wrote:
> Updates are often rather sloppy, though.
I think we're in agreement. It's the updates I was trying to draw attention
to. I agree that the *initial* copyright notice upon first commit is almost
always accurately added. I apologize if I gave the impression that I thought
the *initial* one was sloppy, too.
--
Bradley M. Kuhn - he/him
Policy Fellow & Hacker-in-Residence at Software Freedom Conservancy
========================================================================
Become a Conservancy Supporter today: https://sfconservancy.org/supporter
^ permalink raw reply [flat|nested] 86+ messages in thread
* Re: Seeking input from developers: glibc copyright assignment policy.
2021-07-04 18:32 ` Paul Eggert
2021-07-04 23:25 ` Bradley M. Kuhn
@ 2021-07-05 5:28 ` Carlos O'Donell
2021-07-05 20:21 ` Paul Eggert
1 sibling, 1 reply; 86+ messages in thread
From: Carlos O'Donell @ 2021-07-05 5:28 UTC (permalink / raw)
To: Paul Eggert, Florian Weimer
Cc: DJ Delorie, Dmitry V. Levin, Bruno Haible, libc-alpha
On 7/4/21 2:32 PM, Paul Eggert wrote:
> On 7/4/21 4:55 AM, Florian Weimer wrote:
>> I would prefer something along the lines “Copyright The glibc
>> Contributors”. No year or year range, no individual names.
>> Listing years is apparently not legally required
>
> That's an oversimplification of copyright law. In the US although no
> copyright notice is legally *required* to hold a copyright, there are
> legal *benefits* to having a proper copyright notice, and the FSF
> surely wants those benefits. So at the very least the FSF must be
> specifically listed in the copyright notice of any file containing
> material copyrighted by the FSF.
We would absolutely continue to honour the requests of the FSF to have
their copyright notice included in the files.
Likewise under DCO we would always have a notice indicating that the
work is copyrighted.
> Whether non-FSF copyright owners want to forgo those benefits, is up
> to them. The DCO Sign-off form I've seen doesn't mention this issue,
> so it'd be safer (and more polite) to list each copyright owner.
It is procedurally easier to use a group name: "The GNU Toolchain Authors"
but we can honour requests to do otherwise.
> A proper copyright notice consists of (1) "©" or "Copyright" or
> "Copr.", (2) the year(s) of first publication of the work, and (3)
> the name(s) of the copyright owner(s). For more details, please see
> Chapter 2200 "Notice of Copyright" of the Compendium of US Copyright
> Office Practices, 3rd edition (2021)
> <https://www.copyright.gov/comp3/chap2200/ch2200-notice.pdf>.
As you note, this is not required under the current established
international conventions.
--
Cheers,
Carlos.
^ permalink raw reply [flat|nested] 86+ messages in thread
* Re: Seeking input from developers: glibc copyright assignment policy.
2021-07-05 5:28 ` Carlos O'Donell
@ 2021-07-05 20:21 ` Paul Eggert
2021-07-06 18:05 ` Bradley M. Kuhn
0 siblings, 1 reply; 86+ messages in thread
From: Paul Eggert @ 2021-07-05 20:21 UTC (permalink / raw)
To: Carlos O'Donell, Florian Weimer
Cc: DJ Delorie, Dmitry V. Levin, Bruno Haible, libc-alpha
On 7/4/21 10:28 PM, Carlos O'Donell wrote:
> It is procedurally easier to use a group name: "The GNU Toolchain Authors"
> but we can honour requests to do otherwise.
OK, so the start of the file with some DCOed contributions would look
something like this?
/* Word-wrapping and line-truncating streams.
Copyright (C) 1997-2022 Free Software Foundation, Inc.
Copyright (C) 2021-2022 The GNU Toolchain Authors.
This file is part of the GNU C Library.
The GNU C Library is free software; you can redistribute it ...
This is assuming all the DCOed contributers are OK with not being
mentioned explicitly. This approach should work.
^ permalink raw reply [flat|nested] 86+ messages in thread
* Re: Seeking input from developers: glibc copyright assignment policy.
2021-07-05 20:21 ` Paul Eggert
@ 2021-07-06 18:05 ` Bradley M. Kuhn
2021-07-06 19:42 ` Paul Eggert
0 siblings, 1 reply; 86+ messages in thread
From: Bradley M. Kuhn @ 2021-07-06 18:05 UTC (permalink / raw)
To: Paul Eggert
Cc: Carlos O'Donell, Florian Weimer, libc-alpha, Bruno Haible,
Dmitry V. Levin
> On 7/4/21 10:28 PM, Carlos O'Donell wrote:
> > It is procedurally easier to use a group name: "The GNU Toolchain Authors"
> > but we can honour requests to do otherwise.
Paul Eggert wrote:
> OK, so the start of the file with some DCOed contributions would look
> something like this?
>
> /* Word-wrapping and line-truncating streams.
> Copyright (C) 1997-2022 Free Software Foundation, Inc.
> Copyright (C) 2021-2022 The GNU Toolchain Authors.
Is the “GNU Toolchain Authors” a entity that legally exists? Only a real
entity should be listed in a copyright notice. I talked about this in
detail in my earlier post a few days ago:
https://sourceware.org/pipermail/libc-alpha/2021-July/128467.html
Quoting the relevant part of that email:
>> it's a big mistake to create a copyright notice that lists as the legal
>> entity as something that has no legal standing. So, unless you plan to
>> form an organization called “the glibc Contributors” [or “GNU Toolchain
>> Authors” ], I advise against that notice. [... IANAL and TINLA]
As a way to mitigate this problem and get closer to what you're trying to do,
I make the case again for moving glibc from a file-by-file copyright
inventory mechanism to a single, toplevel file one as I outlined in that
post. Conservancy can probably spare resources to help if you'd like to do
that.
Joseph Myers wrote:
>>> with no date specified and not naming individual contributors, following
>>> the recommendations at
>>> <https://www.linuxfoundation.org/en/blog/copyright-notices-in-open-source-software-projects/>.
These recommendations, and similar ones promulgated by the LF and its SPDX
project, are considered controversial, and legal experts have not formed
consensus around them; by contrast, they are still hotly debated in FOSS
legal and licensing circles. I began proposing the toplevel file COPYRIGHT
notice mechanism as a compromise that solved many of the concerns on both
sides (desire for accurate and complete info vs. the desire for brevity in
a file-by-file situation). I don't purport it to be a pancea, but it has
some real advantages.
There are also political and negative policy outcomes from failing to
list every copyright holder; I wrote on this issue, which to add a bit of
humor to a dry subject, I dubbed "a Gilligan's Island Copyright Notice":
http://ebb.org/bkuhn/blog/2011/06/28/gilligans-island.html
.. the problem has not substantially changed since that blog post.
--
Bradley M. Kuhn - he/him
Policy Fellow & Hacker-in-Residence at Software Freedom Conservancy
========================================================================
Become a Conservancy Supporter today: https://sfconservancy.org/supporter
^ permalink raw reply [flat|nested] 86+ messages in thread
* Re: Seeking input from developers: glibc copyright assignment policy.
2021-07-06 18:05 ` Bradley M. Kuhn
@ 2021-07-06 19:42 ` Paul Eggert
[not found] ` <YOTTfm12jac/NYe5@ebb.org>
0 siblings, 1 reply; 86+ messages in thread
From: Paul Eggert @ 2021-07-06 19:42 UTC (permalink / raw)
To: Bradley M. Kuhn
Cc: Carlos O'Donell, Florian Weimer, libc-alpha, Bruno Haible,
Dmitry V. Levin
On 7/6/21 11:05 AM, Bradley M. Kuhn wrote:
> Is the “GNU Toolchain Authors” a entity that legally exists? Only a real
> entity should be listed in a copyright notice.
Yes and no. It's OK for a copyright notice to identify owners by
reference instead of by naming them explicitly. See section 2205.2(F) of
the Copyright Compendium I mentioned earlier
<https://www.copyright.gov/comp3/chap2200/ch2200-notice.pdf>. It gives
"copyright by publisher" as an example, where the publisher must be
obvious from the rest of the document content.
You're right, though, that without a clear statement of how one maps the
phrase "GNU Toolchain Authors" to what the phrase refers to, the
copyright notice would be defective. So far, we haven't come up with a
clear statement.
Legally speaking, we don't *need* to do anything to the copyright
notices, if the DCO contributors are OK with that. That is, we can leave
the existing copyright notices as-is, and not mention DCOed contributors
at all, unless their contributions contain their copyright notices. That
would be simplest, in terms of meaning the fewest changes to existing
source code. However, if we do this we should make the procedure clear
to everyone concerned.
> I make the case again for moving glibc from a file-by-file copyright
> inventory mechanism to a single, toplevel file
I agree that it'd be helpful to have such a file if well-maintained,
regardless of whether we make changes to the existing copyright notices.
I'd welcome contributions along those lines.
^ permalink raw reply [flat|nested] 86+ messages in thread
* Re: Seeking input from developers: glibc copyright assignment policy.
2021-07-04 11:55 ` Florian Weimer
2021-07-04 18:32 ` Paul Eggert
@ 2021-07-05 5:00 ` Carlos O'Donell
2021-07-05 5:28 ` Florian Weimer
1 sibling, 1 reply; 86+ messages in thread
From: Carlos O'Donell @ 2021-07-05 5:00 UTC (permalink / raw)
To: Florian Weimer, Paul Eggert
Cc: DJ Delorie, Dmitry V. Levin, Bruno Haible, libc-alpha
On 7/4/21 7:55 AM, Florian Weimer wrote:
> * Paul Eggert:
>
>> Following up on this, I propose that if DCO'ed contributions are
>> accepted for a file, the file should contain a proper copyright notice
>> listing the authors and the range of years that each
>> contributed. E.g., the start of the file would look like this:
>>
>> /* Word-wrapping and line-truncating streams.
>> Copyright (C) 1997-2022 Free Software Foundation, Inc.
>> Copyright (C) 2021-2022 Alejandro Davis.
>> Copyright (C) 2022 Sharon Carter, Debra Lindsey.
>> This file is part of the GNU C Library.
>>
>> The GNU C Library is free software; you can redistribute it ...
>>
>> This issue shouldn't arise for Glibc files shared with Gnulib, as
>> they'll still follow the current policy.
>
> I would prefer something along the lines “Copyright The glibc
> Contributors”. No year or year range, no individual names. Listing
> years is apparently not legally required, and naming individual authors
> is also optional. See:
>
> Copyright Notices in Open Source Software Projects
> <https://www.linuxfoundation.org/en/blog/copyright-notices-in-open-source-software-projects/>
The GCC SC suggestion is as follows:
"The GNU Toolchain Authors"
https://gcc.gnu.org/pipermail/gcc/2021-June/236217.html
All files that receive DCO'd material for the first time
would add the following line:
"Copyright The GNU Toolchain Authors"
in the header comment.
--
Cheers,
Carlos.
^ permalink raw reply [flat|nested] 86+ messages in thread
* Re: Seeking input from developers: glibc copyright assignment policy.
2021-07-05 5:00 ` Carlos O'Donell
@ 2021-07-05 5:28 ` Florian Weimer
0 siblings, 0 replies; 86+ messages in thread
From: Florian Weimer @ 2021-07-05 5:28 UTC (permalink / raw)
To: Carlos O'Donell
Cc: Paul Eggert, DJ Delorie, Dmitry V. Levin, Bruno Haible, libc-alpha
* Carlos O'Donell:
> On 7/4/21 7:55 AM, Florian Weimer wrote:
>> * Paul Eggert:
>>
>>> Following up on this, I propose that if DCO'ed contributions are
>>> accepted for a file, the file should contain a proper copyright notice
>>> listing the authors and the range of years that each
>>> contributed. E.g., the start of the file would look like this:
>>>
>>> /* Word-wrapping and line-truncating streams.
>>> Copyright (C) 1997-2022 Free Software Foundation, Inc.
>>> Copyright (C) 2021-2022 Alejandro Davis.
>>> Copyright (C) 2022 Sharon Carter, Debra Lindsey.
>>> This file is part of the GNU C Library.
>>>
>>> The GNU C Library is free software; you can redistribute it ...
>>>
>>> This issue shouldn't arise for Glibc files shared with Gnulib, as
>>> they'll still follow the current policy.
>>
>> I would prefer something along the lines “Copyright The glibc
>> Contributors”. No year or year range, no individual names. Listing
>> years is apparently not legally required, and naming individual authors
>> is also optional. See:
>>
>> Copyright Notices in Open Source Software Projects
>> <https://www.linuxfoundation.org/en/blog/copyright-notices-in-open-source-software-projects/>
>
> The GCC SC suggestion is as follows:
>
> "The GNU Toolchain Authors"
> https://gcc.gnu.org/pipermail/gcc/2021-June/236217.html
>
> All files that receive DCO'd material for the first time
> would add the following line:
>
> "Copyright The GNU Toolchain Authors"
>
> in the header comment.
I had missed that. It works for me, both the string and the rule about
adding it to files (that is, only for files with DCO contributions).
Thanks,
Florian
^ permalink raw reply [flat|nested] 86+ messages in thread
* Re: Seeking input from developers: glibc copyright assignment policy.
2021-07-03 1:59 ` Paul Eggert
2021-07-04 0:40 ` Paul Eggert
@ 2021-07-05 20:37 ` Joseph Myers
1 sibling, 0 replies; 86+ messages in thread
From: Joseph Myers @ 2021-07-05 20:37 UTC (permalink / raw)
To: Paul Eggert
Cc: Carlos O'Donell, DJ Delorie, Dmitry V. Levin, Bruno Haible,
libc-alpha
On Fri, 2 Jul 2021, Paul Eggert wrote:
> On 7/2/21 3:33 PM, Carlos O'Donell wrote:
>
> > gnulib has been including non-FSF copyrighted material in various
> > modules (that include the files below) for a long time.
>
> If gnulib-tool modifies any of those non-FSF copyright notices, then that's a
> bug that should be fixed. It doesn't modify the first one, so we should be OK
> there. (I didn't check the others.)
>
> This raises another issue. What will be the glibc policy about putting
> copyright notices on files containing DCOed material? Will there be a separate
> copyright notice for each contributor? Linux doesn't do that - which is too
> sloppy for glibc, surely. I don't know what GCC plans to do.
I suggest using the same form as agreed by the GCC Steering Committee for
use in GCC:
Copyright The GNU Toolchain Authors.
with no date specified and not naming individual contributors, following
the recommendations at
<https://www.linuxfoundation.org/en/blog/copyright-notices-in-open-source-software-projects/>.
--
Joseph S. Myers
joseph@codesourcery.com
^ permalink raw reply [flat|nested] 86+ messages in thread
* Re: Seeking input from developers: glibc copyright assignment policy.
2021-07-02 22:33 ` Carlos O'Donell
2021-07-03 1:59 ` Paul Eggert
@ 2021-07-03 3:24 ` Bruno Haible
2021-07-05 5:53 ` Carlos O'Donell
1 sibling, 1 reply; 86+ messages in thread
From: Bruno Haible @ 2021-07-03 3:24 UTC (permalink / raw)
To: Carlos O'Donell; +Cc: Paul Eggert, DJ Delorie, Dmitry V. Levin, libc-alpha
Carlos O'Donell wrote:
> gnulib already accepts such code.
>
> gnulib has been including non-FSF copyrighted material in various
> modules (that include the files below) for a long time.
Yes. But the article "Our need for copyright papers has not gone away"
by Richard Stallman explains, among other things, that it makes a big
difference whether a small part or a large part of the package is not
covered by copyright assignments.
In the case of Gnulib so far, it's less than 2% of the code. That's
a small part of Gnulib.
It would be much, much worse if a *large* part of Gnulib was not
covered by copyright assignments.
Similarly, Bradley Kuhn [1] reminded to think about the *long term* mix
of copyright holders.
Bruno
[1] https://sourceware.org/pipermail/libc-alpha/2021-June/128303.html
^ permalink raw reply [flat|nested] 86+ messages in thread
* Re: Seeking input from developers: glibc copyright assignment policy.
2021-07-03 3:24 ` Bruno Haible
@ 2021-07-05 5:53 ` Carlos O'Donell
0 siblings, 0 replies; 86+ messages in thread
From: Carlos O'Donell @ 2021-07-05 5:53 UTC (permalink / raw)
To: Bruno Haible; +Cc: Paul Eggert, DJ Delorie, Dmitry V. Levin, libc-alpha
On 7/2/21 11:24 PM, Bruno Haible wrote:
> Carlos O'Donell wrote:
>> gnulib already accepts such code.
>>
>> gnulib has been including non-FSF copyrighted material in various
>> modules (that include the files below) for a long time.
>
> Yes. But the article "Our need for copyright papers has not gone away"
> by Richard Stallman explains, among other things, that it makes a big
> difference whether a small part or a large part of the package is not
> covered by copyright assignments.
Has that article been published publicly?
> In the case of Gnulib so far, it's less than 2% of the code. That's
> a small part of Gnulib.
Is that "small" from a legal perspective?
It's still non-FSF copyrighted code.
> It would be much, much worse if a *large* part of Gnulib was not
> covered by copyright assignments.
Do you see this changing suddenly?
> Similarly, Bradley Kuhn [1] reminded to think about the *long term* mix
> of copyright holders.
Absolutely. We should keep an eye on that.
--
Cheers,
Carlos.
^ permalink raw reply [flat|nested] 86+ messages in thread
* Re: Seeking input from developers: glibc copyright assignment policy.
2021-06-14 18:52 Seeking input from developers: glibc copyright assignment policy Carlos O'Donell
` (5 preceding siblings ...)
2021-06-15 3:18 ` DJ Delorie
@ 2021-06-15 3:39 ` Daniel Black
2021-06-15 16:09 ` Josh Triplett
` (5 subsequent siblings)
12 siblings, 0 replies; 86+ messages in thread
From: Daniel Black @ 2021-06-15 3:39 UTC (permalink / raw)
To: libc-alpha
[1] https://developercertificate.org/
>
All,
As a one time attempted contributor I welcome a DCO change. The FSF
labyrinth of wiki pages and contribution options was pretty painful to
navigate, and getting a PDF a week later to print off and send back was too
much (especially as there was low interest in my patch anyway).
Bring it (DCO) on, and I might try a contribution again if I have a need.
Otherwise I'll only consider doing a bug report - the process was excessive.
Daniel Black
^ permalink raw reply [flat|nested] 86+ messages in thread
* Re: Seeking input from developers: glibc copyright assignment policy.
2021-06-14 18:52 Seeking input from developers: glibc copyright assignment policy Carlos O'Donell
` (6 preceding siblings ...)
2021-06-15 3:39 ` Daniel Black
@ 2021-06-15 16:09 ` Josh Triplett
2021-06-16 13:01 ` Alyssa Ross
` (4 subsequent siblings)
12 siblings, 0 replies; 86+ messages in thread
From: Josh Triplett @ 2021-06-15 16:09 UTC (permalink / raw)
To: libc-alpha
On Mon, Jun 14, 2021 at 02:52:03PM -0400, Carlos O'Donell wrote:
> 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.
This is incredibly good news.
I've previously made *minor* contributions to glibc under my previous
employer's copyright assignment, but I'm quite interested in
contributing in the future in the absence of an assignment requirement.
I care about glibc. For context, I spent substantial time and effort in
the Rust project making it possible to do static linking with glibc, not
just with musl, because I preferred to use glibc and I wanted to make
sure that glibc was available for people to use for that use case. I'm
really looking forward to the glibc improvements to NSS that will make
static linking even more functional. I'd like to do more in this area.
I'm also interested in the long-term health of glibc, and I think this
change will enable more people to contribute, by removing a legal hurdle
that not everyone can or wants to meet, and by not discouraging
prospective contributors.
Would this step also make it possible for people to contribute
third-party Free Software code to glibc? (DCO clause (b) suggests that
it's fine to contribute code based on work under an appropriate license
that allows such contribution.)
Thank you for starting this process!
^ permalink raw reply [flat|nested] 86+ messages in thread
* Re: Seeking input from developers: glibc copyright assignment policy.
2021-06-14 18:52 Seeking input from developers: glibc copyright assignment policy Carlos O'Donell
` (7 preceding siblings ...)
2021-06-15 16:09 ` Josh Triplett
@ 2021-06-16 13:01 ` Alyssa Ross
2021-06-16 14:08 ` Adam Sampson
` (3 subsequent siblings)
12 siblings, 0 replies; 86+ messages in thread
From: Alyssa Ross @ 2021-06-16 13:01 UTC (permalink / raw)
To: Carlos O'Donell
Cc: libc-alpha, Jakub Jelinek, Joseph S. Myers, Maxim Kuvyrkov
[-- Attachment #1: Type: text/plain, Size: 2553 bytes --]
On Mon, Jun 14, 2021 at 02:52:03PM -0400, Carlos O'Donell via Libc-alpha wrote:
> 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.
I've recently contributed a couple of patches to glibc, and the copyright
assignment was definitely a barrier. I have no employer or university
affiliation, so copyright wasn't an issue, and I also don't mind
assigning copyright to the FSF, because regardless of everything else
that's going on, I don't believe they're going to abuse my copyright.
But even though I should be the simplest case, it still really got in
the way of my patch, because it took 14 days after I requested the form
for me to receive it, and then another 7 days after I returned it for
it to be confirmed. That's a long time for both the reviewer and the
contributor to keep a small patch in their head!
So I'm in favour of allowing DCO. I'd definitely have chosen it over a
copyright assignment had it been available. I don't particularly foresee
any negative consequences that could come of it, especially since the
FSF would probably continue to hold the vast majority of the copyright
for the foreseeable future. And I definitely think it would help get
more contributions, because I know how close I was to just giving up.
> Signed,
> Ryan Arnold
> Paul Eggert
> Jakub Jelinek
> Maxim Kuvyrkov
> Joseph Myers
> Carlos O'Donell
>
> [1] https://developercertificate.org/
>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 86+ messages in thread
* Re: Seeking input from developers: glibc copyright assignment policy.
2021-06-14 18:52 Seeking input from developers: glibc copyright assignment policy Carlos O'Donell
` (8 preceding siblings ...)
2021-06-16 13:01 ` Alyssa Ross
@ 2021-06-16 14:08 ` Adam Sampson
2021-06-16 19:33 ` Joseph Myers
2021-06-16 19:45 ` Phil Blundell
` (2 subsequent siblings)
12 siblings, 1 reply; 86+ messages in thread
From: Adam Sampson @ 2021-06-16 14:08 UTC (permalink / raw)
To: Carlos O'Donell via Libc-alpha
Carlos O'Donell via Libc-alpha <libc-alpha@sourceware.org> writes:
> The changes to accept patches with or without FSF copyright assignment
> would be effective on August 2nd, and would apply to all open
> branches.
This sounds like a sensible approach. One suggestion I'd make here is to
have some clear guidance on how you want to manage copyright notices in
source files as part of the development process, since there's quite a
bit of variation in practice here in other projects.
For example, do you want DCO contributors to add copyright notices to
individual files as part of their changes, or will the maintainers add
them when merging, or will you collect them in a separate file? How do
you prefer (international) names and email addresses to be formatted?
(There is some guidance on copyright notices in the GNU Information for
Maintainers, but it's mostly aimed at FSF-copyright projects at the
moment: https://www.gnu.org/prep/maintain/maintain.html#Copyright-Notices )
Thanks,
--
Adam Sampson <ats@offog.org> <http://offog.org/>
^ permalink raw reply [flat|nested] 86+ messages in thread
* Re: Seeking input from developers: glibc copyright assignment policy.
2021-06-16 14:08 ` Adam Sampson
@ 2021-06-16 19:33 ` Joseph Myers
0 siblings, 0 replies; 86+ messages in thread
From: Joseph Myers @ 2021-06-16 19:33 UTC (permalink / raw)
To: Adam Sampson; +Cc: Carlos O'Donell via Libc-alpha
On Wed, 16 Jun 2021, Adam Sampson via Libc-alpha wrote:
> For example, do you want DCO contributors to add copyright notices to
> individual files as part of their changes, or will the maintainers add
> them when merging, or will you collect them in a separate file? How do
> you prefer (international) names and email addresses to be formatted?
What the GCC Steering Committee agreed was that non-assigned contributions
should use notices of the form
Copyright The GNU Toolchain Authors.
with no date specified and not naming individual contributors, following
the recommendations at
<https://www.linuxfoundation.org/en/blog/copyright-notices-in-open-source-software-projects/>.
--
Joseph S. Myers
joseph@codesourcery.com
^ permalink raw reply [flat|nested] 86+ messages in thread
* Re: Seeking input from developers: glibc copyright assignment policy.
2021-06-14 18:52 Seeking input from developers: glibc copyright assignment policy Carlos O'Donell
` (9 preceding siblings ...)
2021-06-16 14:08 ` Adam Sampson
@ 2021-06-16 19:45 ` Phil Blundell
2021-06-30 21:54 ` Bradley M. Kuhn
2021-06-30 22:21 ` Mark Wielaard
12 siblings, 0 replies; 86+ messages in thread
From: Phil Blundell @ 2021-06-16 19:45 UTC (permalink / raw)
To: Carlos O'Donell
Cc: libc-alpha, Jakub Jelinek, Joseph S. Myers, Maxim Kuvyrkov
On Mon, Jun 14, 2021 at 02:52:03PM -0400, Carlos O'Donell via Libc-alpha wrote:
> 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:
I support this proposal.
Phil
^ permalink raw reply [flat|nested] 86+ messages in thread
* Re: Seeking input from developers: glibc copyright assignment policy.
2021-06-14 18:52 Seeking input from developers: glibc copyright assignment policy Carlos O'Donell
` (10 preceding siblings ...)
2021-06-16 19:45 ` Phil Blundell
@ 2021-06-30 21:54 ` Bradley M. Kuhn
2021-07-01 5:24 ` Siddhesh Poyarekar
` (2 more replies)
2021-06-30 22:21 ` Mark Wielaard
12 siblings, 3 replies; 86+ messages in thread
From: Bradley M. Kuhn @ 2021-06-30 21:54 UTC (permalink / raw)
To: libc-alpha
Dear glibc Software Developer Community,
I have read this thread with interest, and I hope that it is acceptable for
me to share my comments. Even though I personally have never put code into
glibc, I *have* helped over the years with various issues around licensing
in glibc (before the abrupt end to my affiliation with the FSF in 2019). I
hope that past work to help glibc, and my general work in the Free and Open
Source Software community on copyleft enforcement, compliance, and policy
means that my opinions here are useful. However, if decision-making input
here is welcome only from those who have code in glibc, I understand
completely and, if so, please ignore this interruption!
* * *
Much of the discussion I've seen here has contrasted the DCO with a
copyright assignment process. I am particularly appreciative for those who
have pointed out that's not the case: the DCO and copyright assignment
policies are orthogonal issues. I fully support use of a DCO for glibc,
although I recommend the Samba one myself (See
<https://www.samba.org/samba/devel/copyright-policy.html>). Regardless of
which DCO you pick, you could implement most any DCO and keep copyright
assignment; the two ultimately have little to do with each other.
The key quesiton at hand, thus, is whether to continue or curtail the
mandated copyright assignment to FSF for regular/frequent contributors.
While I have previously assigned my own copyright to the FSF (*both* as
"work-for-hire" and "signed assignment form" manner), I personally wouldn't
assign any new copyrights to FSF at this time for various reasons.
Therefore, I am personally sympathetic to those of you who do not want to
assign anymore.
Nevertheless, I feel much of this discussion is missing a few of the key
nuances that are highly relevant to ending the copyright assignment mandate.
Most importantly, the current proposal does not make recommendations on what
developers should do (and/or how they should organize) to assure that they
will ultimately keep their own copyrights when the existing copyright
assignment legal infrastructure starts to atrophy after the policy change.
By default, most copyrights revert to the employer when you contribute to a
codebase as part of your job.
A few commentors on this list claim that *in theory*, this policy change
opens a world of possibility and diversity of where the copyright ownership
lands. However, given work-for-hire doctrine in the USA (and similar rules
around the world), it's highly unlikely that theory will come to fruition in
practice without a clear plan. Most future contributions may well revert to
emloyer-owned. Only collective organization by developers *before* the
policy change takes effect can prevent that.
I thus strongly urge caution, and more careful consideration about the
ramifications of where copyright will land going forward, including (but not
exclusively limited to) a long extension of the current July 1st deadline.
Three questions that I have yet to see addressed in this thread include:
* What do we anticipate the long term mix of copyright holders (say, 5
years from now) will be in glibc once copyright assignment is wholly
optional?
* Will whoever holds the future copyright be willing to enforce the
LGPL? (That's particular important given that LGPL/GPL violations
are quite common on glibc.)
* Will that copyright holder adhere to well-established community
principles and a committment to the public good when doing that
enforcement?
These are just a few questions among dozens that will quickly become
paramount once glibc starts its move to a primarily multi-copyright-held
(from a primarily overwhelming-majority-single-copyright-held) project. Of
course, glibc isn't the only project facing these questions. As such, in
response to these recent changes under consideration by GCC, glibc, and
gnulib, I've written a comprehensive essay that (while quite long) raises
all the questions and concerns that I have about this change. If you're
interested, you can read it here:
https://sfconservancy.org/blog/2021/jun/30/who-should-own-foss-copyrights/
I also offer myself and my colleagues at Software Freedom Conservancy as a
resource to help you investigate these questions if you're interested (as
one of my colleague already did for (see
<https://gcc.gnu.org/pipermail/gcc/2021-June/236257.html>) Personally, I've
spent a career studying the policy questions and observing their
consequences in real world scenarios, and organizationally Conservancy has
done the same. I'd be thrilled to share that knowledge with you.
Finally, I saw a few folks in this thread wondering about "what the lawyers
have said" or what they think. Keep in mind: I personally am not a lawyer,
and Conservancy is not a law firm and we won't and cannot give you legal
advice. However, I do urge you all to talk to your lawyers about this.
However, keep in mind also that "the lawyers at work" are the lawyers for
your company, not for you personally or the glibc project. As such, lawyers
at your workplace will gladly give you legal advice that is in the best
interest of the company, but they don't represent your interests nor glibc's
interests. It's important that you have someone looking out for *your*
legal interests and the legal interests of glibc as a project. Sometimes
those interests will align with your employer, and sometimes they won't. If
you're looking for a lawyer for yourself, while I don't know anyone who does
such work pro-bono, I do know a lot of lawyers who would gladly give you a
"low bono" rate. If you write my privately, I'll try to give you a
recommendation of an attorney to reach out to.
In closing, I ask everyone to consider the efficacy of, enforcement of, and
future compliance with copyleft licenses in making this momentous decision.
Thanks for your time in reading this email, and hopefully -- yes, I know
it's a wall of text -- in reading my longer essay on the subject:
https://sfconservancy.org/blog/2021/jun/30/who-should-own-foss-copyrights/
Sincerely,
--
Bradley M. Kuhn - he/him
Policy Fellow & Hacker-in-Residence at Software Freedom Conservancy
========================================================================
Become a Conservancy Supporter today: https://sfconservancy.org/supporter
^ permalink raw reply [flat|nested] 86+ messages in thread
* Re: Seeking input from developers: glibc copyright assignment policy.
2021-06-30 21:54 ` Bradley M. Kuhn
@ 2021-07-01 5:24 ` Siddhesh Poyarekar
2021-07-01 19:33 ` Bradley M. Kuhn
2021-07-01 8:19 ` Alexandre Oliva
2021-07-02 8:59 ` Florian Weimer
2 siblings, 1 reply; 86+ messages in thread
From: Siddhesh Poyarekar @ 2021-07-01 5:24 UTC (permalink / raw)
To: Bradley M. Kuhn, libc-alpha
On 7/1/21 3:24 AM, Bradley M. Kuhn wrote:
> Dear glibc Software Developer Community,
Thank you for writing this and the blog post. I share my 2p as a long
time contributor but I'm not ashamed to admit that there are others who
would have far more educated opinions.
> I have read this thread with interest, and I hope that it is acceptable for
> me to share my comments. Even though I personally have never put code into
> glibc, I *have* helped over the years with various issues around licensing
> in glibc (before the abrupt end to my affiliation with the FSF in 2019). I
> hope that past work to help glibc, and my general work in the Free and Open
> Source Software community on copyleft enforcement, compliance, and policy
> means that my opinions here are useful. However, if decision-making input
> here is welcome only from those who have code in glibc, I understand
> completely and, if so, please ignore this interruption!
>
> * * *
>
> Much of the discussion I've seen here has contrasted the DCO with a
> copyright assignment process. I am particularly appreciative for those who
> have pointed out that's not the case: the DCO and copyright assignment
> policies are orthogonal issues. I fully support use of a DCO for glibc,
> although I recommend the Samba one myself (See
> <https://www.samba.org/samba/devel/copyright-policy.html>). Regardless of
> which DCO you pick, you could implement most any DCO and keep copyright
> assignment; the two ultimately have little to do with each other.
This looks quite good. There would be practical concerns, i.e. who
becomes the custodian of such records, but they're not insurmountable.
> The key quesiton at hand, thus, is whether to continue or curtail the
> mandated copyright assignment to FSF for regular/frequent contributors.
> While I have previously assigned my own copyright to the FSF (*both* as
> "work-for-hire" and "signed assignment form" manner), I personally wouldn't
> assign any new copyrights to FSF at this time for various reasons.
> Therefore, I am personally sympathetic to those of you who do not want to
> assign anymore.
>
> Nevertheless, I feel much of this discussion is missing a few of the key
> nuances that are highly relevant to ending the copyright assignment mandate.
> Most importantly, the current proposal does not make recommendations on what
> developers should do (and/or how they should organize) to assure that they
> will ultimately keep their own copyrights when the existing copyright
> assignment legal infrastructure starts to atrophy after the policy change.
> By default, most copyrights revert to the employer when you contribute to a
> codebase as part of your job.
>
> A few commentors on this list claim that *in theory*, this policy change
> opens a world of possibility and diversity of where the copyright ownership
> lands. However, given work-for-hire doctrine in the USA (and similar rules
> around the world), it's highly unlikely that theory will come to fruition in
> practice without a clear plan. Most future contributions may well revert to
> emloyer-owned. Only collective organization by developers *before* the
> policy change takes effect can prevent that.
I strongly believe dropping the assignment requirement makes it easier
for developers to get involved. However, I don't see that changing the
structure of copyright ownership of the glibc code base by much in the
short or medium term.
The change in copyright ownership may change in the long term, but given
the current contributions, I still expect the majority to stay with the
FSF and a handful of companies, some of whom have been targets in the
past of frivolous copyright claims in Open Source code. That won't be
too different from the Linux project, where a bulk of the code in the
core kernel originates from a handful of companies. If anything, it's
likely to be even more constrained.
> I thus strongly urge caution, and more careful consideration about the
> ramifications of where copyright will land going forward, including (but not
> exclusively limited to) a long extension of the current July 1st deadline.
>
> Three questions that I have yet to see addressed in this thread include:
>
> * What do we anticipate the long term mix of copyright holders (say, 5
> years from now) will be in glibc once copyright assignment is wholly
> optional?
Like I said above, in the long term the mix may change, but I still
don't expect the FSF ownership to be diluted by much for various
reasons. Even if there were dilution, I don't expect it to diverge too
much from the handful of organizations that currently pitch in to
maintain glibc. I think there are predictable patterns to those
contributions too in terms of which sources are touched by which
individuals/organizations.
> * Will whoever holds the future copyright be willing to enforce the
> LGPL? (That's particular important given that LGPL/GPL violations
> are quite common on glibc.)
>
> * Will that copyright holder adhere to well-established community
> principles and a committment to the public good when doing that
> enforcement?
I believe the FSF would have enough of a copyright stake in glibc even
in the long term to have the means and the incentive to do that. However
like you mentioned in your blog post (and I've heard from others in a
significantly less polite manner and long before the internal crisis you
mentioned), the FSF isn't exactly rushing to act on violations and
enforcement.
I'm under no illusion that for profit companies would actively seek out
violators and help get them on course to compliance since it does not
affect their core business. The SFC enforcement coalition your
colleague mentioned on the gcc list is a great option IMO.
Thanks,
Siddhesh
^ permalink raw reply [flat|nested] 86+ messages in thread
* Re: Seeking input from developers: glibc copyright assignment policy.
2021-07-01 5:24 ` Siddhesh Poyarekar
@ 2021-07-01 19:33 ` Bradley M. Kuhn
2021-07-02 3:29 ` Siddhesh Poyarekar
0 siblings, 1 reply; 86+ messages in thread
From: Bradley M. Kuhn @ 2021-07-01 19:33 UTC (permalink / raw)
To: libc-alpha
Siddhesh Poyarekar wrote at 22:24 (PDT) on Wednesday:
> I strongly believe dropping the assignment requirement makes it easier for
> developers to get involved.
I absolutely agree, and as I indicated in my longer essay, I personally
prefer a model where there is a good mix of copyrights held by individual
contributors and charities both. That is not a new position of mine. My
affiliation with the FSF ended in 2019, but when I previously had
affiliation with the FSF, I was one of the few internal voices who advocated
to relax the copyright assignment processes for GCC, *provided that*
individuals rather companies held the non-FSF-assigned copyrights. I argued
for that internally at the FSF on a semi-regular basis from 2002 right up
until a few moths before my affiliation with the FSF ended in 2019.
*However* …
> I still don't expect the FSF ownership to be diluted by much for various
> reasons.
I think we can't know that for sure one way or the other — unless someone
does the work to:
(a) comb and collate VCS logs to document who the major contributors are,
(b) figure out who their employers are (or were, or will be),
(c) clearly examine how the copyright assignment / disclaimer of copyright
relationships between those companies and the FSF are currently
structured, and
(d) do an analysis of what's likely to happen to those agreements once the
copyright assignment requirement is lifted.
Keep in mind that the copyright assignment/disclaimer arrangements have many
forms and structures; IIUC, most can be revoked. Furthermore, I note that
the deadline day for input on this momentous change is nearing its end, and
there are no statements on this thread from the well-known major employers
involved in glibc about what their intended copyright policy if the FSF
copyright assignment mandate is lifted.
Absent assurances and more information, we must assume the worst case: that
the all new copyrights are owned by the contributors' employers as soon as
the copyright assignment mandate is lifted.
> That won't be too different from the Linux project, where a bulk of the
> code in the core kernel originates from a handful of companies.
This has led to many bad outcomes for Linux. While those outcomes can and
have been (mostly) mitigated, I don't recommend glibc aim to emulate that
model.
> Even if there were dilution, I don't expect it to diverge too much from
> the handful of organizations that currently pitch in to maintain glibc.
Those organizations likely do not share a belief that copyleft should be
enforced for the good of downstream users, so I think that point is bad
news, not good news … which relates to your later point …
> I'm under no illusion that for profit companies would actively seek out
> violators and help get them on course to compliance since it does not
> affect their core business.
… with which I agree.
Meanwhile, on the matter of potential Conservancy involvement:
> The SFC enforcement coalition your colleague mentioned on the gcc list is
> a great option IMO.
I'm glad you think so, and Conservancy does have that form of arrangement
with the Debian project. Debian's primary home in the USA is Software in
the Public Interest, but they have a limited arrangement with Conservancy
regarding voluntary copyright assignments for some contributors, and
enforcement proxy agreements for those who own their copyrights. The best
resource for how that program works is the original announcements:
https://sfconservancy.org/news/2015/aug/17/debian/
https://sfconservancy.org/blog/2015/aug/17/debian/
Most importantly, keep in mind that major Debian contributors approached
Conservancy to request this. Conservancy doesn't unilaterally start these
kinds of programs; we do them when project contributors ask for them. We've
offered to help generally, but no one has asked us for any specific
assistance in the case of glibc, GCC, and gnulib. Beyond general comments
and thoughts (such as this email), we *wouldn't* impose ourselves on the
situation unless explicitly requested. IOW, at the moment, I and
Conservancy aren't involved, other than to give our opinions as folks
knowledgeable on the subject — in response to the public call for comment:
https://sourceware.org/pipermail/libc-alpha/2021-June/127581.html
> I still expect the majority [of the copyright] … to stay with … a handful
> of companies, some of whom have been targets in the past of frivolous
> copyright claims in Open Source code.
I suppose it's possible that companies who contribute to glibc have also
faced frivolous copyright claims on FOSS. (However, such incidents are
extremely rare, though — and, I'm admittedly wondering if you're referencing
the same widely exaggerated tale that I'm thinking of.) Regardless, I think
it's a moot point. Such a situation doesn't imply those companies will
later have the goal of defending the rights of users under copyleft. If
relevant at all, IMO, it cuts the other way: those companies may seek
copyrights for escalation/counter-claims against any enforcement action
(even a legitimate one brought to defend users' rights). Note that, when
they enforce the LGPL and GPL, Conservancy and FSF are both accused of being
“copyright trolls”, and the Defendants *always* call those claims “frivolous”.
--
Bradley M. Kuhn - he/him
Policy Fellow & Hacker-in-Residence at Software Freedom Conservancy
========================================================================
Become a Conservancy Supporter today: https://sfconservancy.org/supporter
^ permalink raw reply [flat|nested] 86+ messages in thread
* Re: Seeking input from developers: glibc copyright assignment policy.
2021-07-01 19:33 ` Bradley M. Kuhn
@ 2021-07-02 3:29 ` Siddhesh Poyarekar
2021-07-03 6:03 ` Eli Zaretskii
0 siblings, 1 reply; 86+ messages in thread
From: Siddhesh Poyarekar @ 2021-07-02 3:29 UTC (permalink / raw)
To: Bradley M. Kuhn, libc-alpha
On 7/2/21 1:03 AM, Bradley M. Kuhn wrote:
> Keep in mind that the copyright assignment/disclaimer arrangements have many
> forms and structures; IIUC, most can be revoked. Furthermore, I note that
> the deadline day for input on this momentous change is nearing its end, and
> there are no statements on this thread from the well-known major employers
> involved in glibc about what their intended copyright policy if the FSF
> copyright assignment mandate is lifted.
For commercial distribution vendors**, I suspect it is not as easy a
decision to withdraw copyright assignment since their contribution to
GNU goes beyond gcc and glibc. For hardware vendors (who form the other
large contingent of contributors) maybe it's not as hard a decision, but
it still involves getting legal to evaluate the change and initiate the
process so I'm not entirely sure given that nobody has actually moved
yet AFAICT.
> Absent assurances and more information, we must assume the worst case: that
> the all new copyrights are owned by the contributors' employers as soon as
> the copyright assignment mandate is lifted.
But for that their assignment has to be terminated, no? If nobody has
moved to do that, the worst case assumption ought to be a little more
benign, i.e. companies start evaluating and withdrawing their
assignments and the change happens more slowly over the coming months/years.
Regardless of that, I reckon the FSF will always have enough of a
copyright stake to allow enforcing copyleft. The glibc code base has
legally significant artifacts at least from the early 90s that have
survived to this date; that's 30 years.
> I suppose it's possible that companies who contribute to glibc have also
> faced frivolous copyright claims on FOSS. (However, such incidents are
> extremely rare, though — and, I'm admittedly wondering if you're referencing
> the same widely exaggerated tale that I'm thinking of.) Regardless, I think
> it's a moot point. Such a situation doesn't imply those companies will
> later have the goal of defending the rights of users under copyleft. If
> relevant at all, IMO, it cuts the other way: those companies may seek
> copyrights for escalation/counter-claims against any enforcement action
> (even a legitimate one brought to defend users' rights). Note that, when
/me nods. Based on my limited knowledge from asking around, it doesn't
look like anybody has moved to terminate their assignments.
Unfortunately I am not privy to the assignment file or the details of
contracts with the FSF so I don't know for sure.
Siddhesh
** I am not speaking for my employer (Red Hat) and this is my personal
impression based on my understanding of how distributions work.
^ permalink raw reply [flat|nested] 86+ messages in thread
* Re: Seeking input from developers: glibc copyright assignment policy.
2021-07-02 3:29 ` Siddhesh Poyarekar
@ 2021-07-03 6:03 ` Eli Zaretskii
0 siblings, 0 replies; 86+ messages in thread
From: Eli Zaretskii @ 2021-07-03 6:03 UTC (permalink / raw)
To: Siddhesh Poyarekar; +Cc: libc-alpha
> From: siddhesh@gotplt.org (Siddhesh Poyarekar)
> Date: Fri, 2 Jul 2021 08:59:10 +0530
>
> > Absent assurances and more information, we must assume the worst case: that
> > the all new copyrights are owned by the contributors' employers as soon as
> > the copyright assignment mandate is lifted.
>
> But for that their assignment has to be terminated, no? If nobody has
> moved to do that
Actually, one contributor already did.
^ permalink raw reply [flat|nested] 86+ messages in thread
* Re: Seeking input from developers: glibc copyright assignment policy.
2021-06-30 21:54 ` Bradley M. Kuhn
2021-07-01 5:24 ` Siddhesh Poyarekar
@ 2021-07-01 8:19 ` Alexandre Oliva
2021-07-02 8:59 ` Florian Weimer
2 siblings, 0 replies; 86+ messages in thread
From: Alexandre Oliva @ 2021-07-01 8:19 UTC (permalink / raw)
To: Bradley M. Kuhn; +Cc: libc-alpha
Hello, Bradley,
Thank you for taking the time to try to influence this community in a
direction that is more conducive to our shared goals of promoting
software freeom than what is being considered.
I've remained mainly silent in this debate, because I feel the climate
and the perceived allegiances I hold, and the emotional rather than
strategic motivations behind these pressure campaigns, are unlikely to
help my arguments be heard, or, worse, are likely to have them taken as
something to be opposed.
I'm glad someone like you, who AFAICT is not afflicted by these
perceptions, has made so clear the risks of corporate takeover, and of
copyleft dilution into meaninglessness. Thank for having done this.
I'd like to subscribe to your recommendation that we don't make this
decision in a hurry, and that we don't take lightly the loss of the
primary leverage we have to keep copyrights, and thus copyleft
enforcement powers, in the hands of organizations that can normally be
counted on to pursue them, and to amount to a credible threat to those
considering deviating from them, instead of approaching these matters
under the shadow of usual corporate interests.
Even if some believe a policy change away from assignments to the FSF
may make things better, they should consider whether they'd really
prefer contributors' employers to keep the copyrights instead. As soon
as the possibility of not contributing copyrights is instated, employers
will have little reason to give much consideration to employee's
requests for assignments or disclaimers.
The leverage will be gone, and existing contracts in which employees
counted on project's requirements and consequent corporate assignments
to land copyrights in hands that are aligned with and committed to
software freedom, may be turned into corporate-held copyrights, without
any actions o even awareness by employees, by having the corporation
unilaterally terminating the assignment for future contributions.
Some may welcome these policy changes as a means to defy and hurt the
FSF and RMS, but ultimately it will hurt harder the project's goals, and
those of its contributors. I'm sure those who are seeding dissent from
behind the curtains, spreading lies, reinforcing incorrect perceptions,
and promoting self-defeating strategies within our ranks, don't mind at
all if we hurt each other and our projects.
--
Alexandre Oliva, happy hacker https://FSFLA.org/blogs/lxo/
Free Software Activist GNU Toolchain Engineer
Disinformation flourishes because many people care deeply about injustice
but very few check the facts. Ask me about <https://stallmansupport.org>
^ permalink raw reply [flat|nested] 86+ messages in thread
* Re: Seeking input from developers: glibc copyright assignment policy.
2021-06-30 21:54 ` Bradley M. Kuhn
2021-07-01 5:24 ` Siddhesh Poyarekar
2021-07-01 8:19 ` Alexandre Oliva
@ 2021-07-02 8:59 ` Florian Weimer
2 siblings, 0 replies; 86+ messages in thread
From: Florian Weimer @ 2021-07-02 8:59 UTC (permalink / raw)
To: Bradley M. Kuhn; +Cc: libc-alpha
* Bradley M. Kuhn:
> Nevertheless, I feel much of this discussion is missing a few of the key
> nuances that are highly relevant to ending the copyright assignment mandate.
> Most importantly, the current proposal does not make recommendations on what
> developers should do (and/or how they should organize) to assure that they
> will ultimately keep their own copyrights when the existing copyright
> assignment legal infrastructure starts to atrophy after the policy change.
> By default, most copyrights revert to the employer when you contribute to a
> codebase as part of your job.
I think in the context of glibc, with copyright assignment to the FSF,
this does not strike me as particularly relevant, given where we are
today.
The current version of the GPL explicitly exempts workers from copyleft
protection, so that they do not enjoy any software freedoms at all:
| You may convey covered works to others for the sole purpose of having
| them make modifications exclusively for you, or provide you with
| facilities for running those works, provided that you comply with the
| terms of this License in conveying all material for which you do not
| control copyright. Those thus making or running the covered works for
| you must do so exclusively on your behalf, under your direction and
| control, on terms that prohibit them from making any copies of your
| copyrighted material outside their relationship with you.
Version 2 of the GPL does not have comparable language, so the situation
was much more murky there.
Consequently, I don't think that for those of us who are concerned about
workers' rights, employers bypassing copyleft, and such like, the FSF is
the right organization to assign copyrights to.
Thanks,
Florian
^ permalink raw reply [flat|nested] 86+ messages in thread
* Re: Seeking input from developers: glibc copyright assignment policy.
2021-06-14 18:52 Seeking input from developers: glibc copyright assignment policy Carlos O'Donell
` (11 preceding siblings ...)
2021-06-30 21:54 ` Bradley M. Kuhn
@ 2021-06-30 22:21 ` Mark Wielaard
12 siblings, 0 replies; 86+ messages in thread
From: Mark Wielaard @ 2021-06-30 22:21 UTC (permalink / raw)
To: libc-alpha
Hi,
On Mon, Jun 14, 2021 at 02:52:03PM -0400, Carlos O'Donell wrote:
> 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.
I talked to some of you already off-list but realized I hadn't
responded publicly. I don't really like this proposal because it is
vague on details and policy. And it doesn't mention any specific goal
for this policy change. This makes it so that the discussion is
somewhat random IMHO because people are just inserting their own goals
and assume this proposal is for or against those.
I noticed that the proposal is signed by just a subset of the
stewards. What is the opinion of the other stewards? And I would
really like to know the opinion of FSF legal on this proposal.
Personally I contribute to glibc and some other GNU projects because
we are all equal participants (when it comes to the rights we have to
the project code) and have the FSF as legal guardian to fall back on
and who we can use to look out for the users, so they will always have
the possibility to get the full corresponding source code of our work
to use and modify as they want. And I know that the FSF will be
reasonable and fair about it:
https://www.fsf.org/licensing/enforcement-principles
The above is possible because of the copyright assignments and maybe
even more importantly the company disclaimers we provide to the FSF. I
appreciate that those assignments are sometimes a bit of work, but
recently having done several personal copyright assignments myself it
is a fairly smooth process, taking just a couple of days. Of course if
you also need a company disclaimer because your employer makes claims
on your work and doesn't have one on file with the FSF might take a
bit more work. But having done that it mostly is figuring out who can
sign the disclaimer. And it makes sure it is not just you who can
freely assign those right to the FSF, but also that the general public
will permanently and irrevocably get those rights.
I don't feel the proposed developer certificate of origin provides
those same guarantees. Especially if we also won't require a company
disclaimer anymore. I fear it will lead to unclear copyright ownership
which might make compliance impossible leading to users not having a
clear contact point when they are looking for the sources to our
works. Or the opposite where a company acquires a substantial amount
of copyright in our work and starts to randomly enforce it and/or
scare their customers/users to "buy" compliance.
There are also practical issues where it will be more difficult to
share code with other GNU projects and/or change the version or
exception statements used in the code. Especially with the current
proposed text of the linux kernel DCO. It would be good to at least
use a text that is tailored to the GNU project.
And as people have pointed out just requiring the "signed-off-by" line
without requiring people explain why or how they are complying with
the DCO (who is the copyright holder? which clause of the DCO are you
complying with?) makes it really hard to track the legal status of the
code.
I can certainly see how a DCO could be helpful with occasional drive
by contributions without creating full chaos as I describe above if
the text was more clear and the processes around it more specific of
how they comply with the DCO and which copyright holder they
represent. But I hope we will still require people making sustainable
contributions (and who want to become maintainers with commit rights)
to assign their copyright and where necessary (because the contributor
doesn't own the work they want to contribute) require company
disclaimers.
Cheers,
Mark
^ permalink raw reply [flat|nested] 86+ messages in thread