I've already stated the legal weakness that the DCO itself has-- this indefinite reference to "the file" for critical license terms, and I explained how I expected it got that way. Did you give a counterargument to that which I have overlooked? Even that Linux Kernel submitting patches document you referred to (I think your link is missing the final letter) doesn't do nearly so much as it could to clarify that point or clearly specify a license grant from the contributor. Surely you don't consider the Linux Kernel code itself to be pure perfection, never possible to improve, so why would you expect their legal practices to be perfect and unimprovable?adrian_broher wrote:...what makes you think that the DCO isn't good enough for this project, when it seems to be good enough for the Linux Kernel
Legally required as in definitely a judge would rule against you without that? No, but any murkiness about the terms people are going to be held accountable for is bad, and a potential source for an adverse ruling. Given that the README.md automatically features prominently in the display by GitHub, the focal point for people to submit contributions to a github-hosted project, it is an ideal place to call attention to anything critical like inbound license terms for contributions to a GitHub project. Our README.md refers contributors to a secondary document for details, which is fine. Whatever site or process is used to gather submissions should make the terms clear, or you're just pointlessly creating an opening for trouble.Is this even required legally? Open source projects that follow the GPL project layout (Having a README, COPYING, CHANGELOG, src, share, ...) you can expect that the COPYING file contains the license terms because of customary practice.Dilvish wrote:Also please note neither README.md for those projects refers to their COPYING file
I agree with the first part of that, putting some language along the lines of the DCO into our CONTRIBUTE.md. I disagree about us needing to institute the git signoff process. As the the documentation for git signoff itself notes, "The meaning of a signoff depends on the project..." i.e., you have to have a clear statement of what you intend the signoff to mean, or it is meaningless. It is that clear statement about the submission process and inbound licenensing requirements which provides the core (almost the entirety) of the project's legal position, regardless of the signoff.Vezzra wrote:So, basically, we would incorporate a properly worded DCO into CONTRIBUTE.md, ideally with an explicit line stating something like "Each commit needs to be signed off, by which the contributor agrees to the projects license terms and releases their contributions according to these terms". Then, all that needs to be done is that each committer actually does that (signing off their commits). Have a CI build stage checking for a correct sign-off, so we can't accidentally merge a PR missing it.
For a project like the Linux Kernel which actually defends itself in litigation, the very tiny little bit of extra proof/notice that the signoff statement provides (about the contributor having notice the actu of submitting and/or providing signoff may be intended to signify agreement to some set of terms) may very well be worth the hassle-cost. Their actual justification for the signoff requirement in that document linked above focuses almost entirely just on some sort of project organizational tracking value. Please also keep in mind that since for projects like the Linux Kernel their contributions are much more likely needing to come from highly skilled programmers compared to the broad range of skill levels that helpful FO contributors can have, the barrier for them is likely much lower than it would be for many of our contributors. So it's worth more to them and costs them less.
Even under the terms of the standard DCO there is nothing that inherently requires the use of --signoff, any such requirement comes purely from the other project docments. As noted in that Software Conservancy article it is just fine to make it clear in the project documents that the act of submitting a contribution constitutes acceptance of the various specified terms regarding such (akin to click-wrap agreement to licensing or terms-of-use). (And that is a longstanding part of contract law, acceptance of a contract can done via taking some specified action, not only via signing something.)
So, like Geoff, I see no reason for us to require git --signoff (but I do think we need to augment our project documents to make these submission terms more clear).