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. Despite what the current marketing departments might tell you, the DCO is not a single document nor was it designed to be. There are many variants throughout the Free Software community to meet the needs of specific projects. (Indeed, the original DCO text was specifically released under CC-By-SA to encourage projects to adapt it to their needs [0].) 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. * * * 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. [0] http://web.archive.org/web/20070306195036/http://osdlab.org/newsroom/press_releases/2004/2004_05_24_dco.html > [1] Link: > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/Documentation/process/submitting-patches.rst?id=d4563201f33a022fc0353033d9dfeb1606a88330 (IANAL and TINLA, but I've regularly studied this policy issue since the DCO was first introduced.) -- Bradley M. Kuhn - he/them Policy Fellow & Hacker-in-Residence at Software Freedom Conservancy ======================================================================== Become a Conservancy Sustainer today: https://sfconservancy.org/sustainer
