Vezzra wrote:How exactly do you think this should work? Do you mean that each and every commit message should include a DCO? If not, that only leaves including the DCO in one of the commits someone contributes to the repo, which would scatter the DCOs across the thousands of commits in our repo. While still a vast improvement to our current policy (IMO), both options don't sound very appealing.
My suggestion would be to create a folder "license statements" (or something like that), and have every contributer commit a text file containing their DCO to that folder (ideally these commits would be signed, but I'm aware that only a minority actually GPG signs their commits). Is that similar to what you had in mind?
Or something else entirely?
I further researched this and the Linux Kernel developers handle it the following way. Inside the submitting-patches.rs
guideline the DCO text is noted verbatim (this file is roughly the equivalent to our CONTRIBUTE.md
). When contributing patches via $SOME_MECHANISM the contributor needs to sign of all of their commits by appending their author signature to the end of the commit message like
Which can also be done by calling git commit
with the -s
This explicit action indicates that the contributor at least understood the CONTRIBUTE.md and DCO and agreed to the terms of both.
On our side a CI build stage could check for us if the author of the commit matches the Signed-off-by statement in the commit message and block a pull request for merge. Which is the point of the clahub, which o0leg linked.
Dilvish wrote:I expect this DCO is probably referred to elsewhere in their license or submission documents, and that reference point would actually be the core legal basis for their position. Requiring people to reference the DCO at least creates a record that the person is specifically on notice that there is probably a license file someplace, "the file", which someone might hold them accountable to at some point, plus it contains these statements about the source of the specific contribution, which is a critical underpinning to the project's overall licensing position.
That would be the submitting-patches.rs mentioned above.
Dilvish wrote:I have a suitable background for the task, if we decide to take that path. If anyone else does also, please speak up.
I don't want to diminish your competences in any way, but 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 (that are somewhat battle proven in terms of fighting of legal issue with various third parties)? Skimming the article you posted suggest to me that either the DCO or relying on implicit agreement by pointing out at many place as possible that everything is licensed under the terms of X. I consider the explicit Agreement with DCO and sign-off more suitable IMO.
Dilvish wrote:Also, is there some particular reason our COPYING file is not instead named LICENSE? Particularly given that we want it to have significance as an inbound license as well as outbound, and to more clearly fit with the DCO, I think it would be better named LICENSE.
It's commonplace to place GPL derived licenses under this file name since... the existence of the the GPL I guess?
Vezzra wrote:I also wonder why it resides in the "default" folder instead of the root directory (where it should be IMO
Because code. The About.cpp accesses that file as resource and would break the development build when moving it to the root dir. But that should be fixable in the deployment scripts.
Dilvish wrote:Also please note neither README.md for those projects refers to their COPYING file
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.