Hi Bradley, Thanks for following the discussion and your input.
We have also been discussing some policy wording changes on gcc-patches: https://inbox.sourceware.org/gcc-patches/20241202101600.1041524-1-m...@klomp.org/T If you have any suggestions for improving the actual wording change that would be appreciated. On Sun, Nov 24, 2024 at 08:49:37AM -0800, Bradley M. Kuhn via Gcc wrote: > Carlos O'Donell wrote on Friday: > > The DCO was introduced to gcc, glibc and binutils in 2021 and 2022 > > to expand and align the contribution process with other free and open > > source software projects that had been effectively using DCO for > > contributions. > > > To that end I'm aligning the glibc usage following the Linux kernel > > changes from 2023-02-26 [1]. > > While the DCO text used by the kernel named Linux is a fine text and serves > many purposes, it is particularly aligned with the sub-maintainer model of > Linux development — whereby submaintainers take cascading responsibility as > patches work their way upstream, and are thus adding Signed-Off-By tags upon > existing Signed-Off-By tags, and thus strengthening the DCO attestation with > addition of more parties for the same patch. > > I am not aware that all of the toolchain projects have a similar model of > development and thus the DCO text that Linux uses may not be ideal. That is a good point. Most projects have a much flatter structure. And developers are often asked to commit patches directly themselves. Just adding Reviewed-by or Tested-by tags. > One size doesn't necessarily fit all. Perhaps if you're changing the DCO > text for the toolchain projects at this moment, it might be a good time to > consider if the Linux DCO text suits your project perfectly. Yeah, for elfutils, libabigail and debugedit we already made a some of clarifications: https://sourceware.org/cgit/elfutils/tree/CONTRIBUTING#n26 Specifically it explains that you contribute under all licenses applicable to the project. Which is important for elfutils since it uses a dual license for some of the included libraries. And we want to prevent someone claiming to have only contributed the code under a lax-permissive license without granting any additional GPL rights. This might be useful for GCC too for some of the code/documentation strings which are distributed under either the GPL or GFDL. > FWIW, my specific concern with the Linux DCO is, as Denver and I discussed in > licensing BoF at Cauldron, the Linux DCO text is specifically designed to > shift licensing liability from any *entity* who might be contributing or who > might hold copyright (such as a company or a non-profit) *onto* the > individual developer who submitted the patch. I suppose this structure works > well for Linux, but, especially given that contributors to the toolchain > projects have been used to all the liability shifting to the FSF through its > historical copyright assignment system, developers might be surprised to > learn that a DCO-based patch (as opposed to a copyright assigned one) puts > additional liability onto the contributor. That is an interesting point. One of the clarifications suggested on gcc-patches was that the DCO process isn't applicable to all contributing situations and following the FSF assignment process might be a good alternative. The FSF process also means you get an explicit company disclaimer. The Samba policy might be something to follow to get an explicit company disclaimer, while still following the "normal" Signed-off-by process. https://www.samba.org/samba/devel/copyright-policy.html We would just need someone to collect the explicit company declarations. Cheers, Mark
