[PATCH/RFC] Developer's Certificate of Origin: default to COPYING
The Developer's Certificate of Origin refers to the open source license indicated in the file, but there is no such indication in most files in the Git repository. Update the text to indicate that the license in COPYING should be assumed if a file doesn't excplicitly indicate which license applies to the file. The phrase accompanies the file was chosen to support different default licenses in different subdirectories (e.g., 2-clause BSD for vcs-svn/*, LGPL2.1+ for xdiff/*). Signed-off-by: Richard Hansen rhan...@bbn.com --- I'm bringing this up because, to this layman's eyes, it seems like a potentially troublesome oversight. IIUC, one of the purposes of the Developer's Certificate of Origin is to make it easy for developers to declare which license covers a contribution. Requiring a license declaration protects the project and its users from copyright litigation. What happens if the file(s) being modified do not indicate which license applies to the file? Is there no license? Does it default to the main project license in COPYING? This lack of clarity makes me a bit nervous (law is already too nondeterministic for my liking), so I'd like to see a change that makes it explicit. Notes: * I am not a lawyer. (Maybe a lawyer should be consulted?) * This change might not be necessary. * This change might be wrong. * I hope I'm not just wasting everyone's time by bringing this up. Documentation/SubmittingPatches | 9 ++--- 1 file changed, 6 insertions(+), 3 deletions(-) diff --git a/Documentation/SubmittingPatches b/Documentation/SubmittingPatches index 7055576..c5ff744 100644 --- a/Documentation/SubmittingPatches +++ b/Documentation/SubmittingPatches @@ -227,13 +227,15 @@ the patch, which certifies that you wrote it or otherwise have the right to pass it on as a open-source patch. The rules are pretty simple: if you can certify the below: -Developer's Certificate of Origin 1.1 +Developer's Certificate of Origin 1.2 By making a contribution to this project, I certify that: (a) The contribution was created in whole or in part by me and I have the right to submit it under the open source license -indicated in the file; or +indicated in the file (or, if no license is indicated in +the file, the license in COPYING that accompanies the +file); or (b) The contribution is based upon previous work that, to the best of my knowledge, is covered under an appropriate open source @@ -241,7 +243,8 @@ pretty simple: if you can certify the below: work with modifications, whether created in whole or in part by me, under the same open source license (unless I am permitted to submit under a different license), as indicated -in the file; or +in the file (or, if no license is indicated in the file, +the license in COPYING that accompanies the file); or (c) The contribution was provided directly to me by some other person who certified (a), (b) or (c) and I have not modified -- 1.8.4 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH/RFC] Developer's Certificate of Origin: default to COPYING
Linus, this is not limited to us, so I am bothering you; sorry about that. My instinct tells me that some competent lawyers at linux-foundation helped you with the wording of DCO, and we amateurs shouldn't be mucking with the text like this patch does at all, but just in case you might find it interesting... Richard Hansen rhan...@bbn.com writes: The Developer's Certificate of Origin refers to the open source license indicated in the file, but there is no such indication in most files in the Git repository. Update the text to indicate that the license in COPYING should be assumed if a file doesn't excplicitly indicate which license applies to the file. The phrase accompanies the file was chosen to support different default licenses in different subdirectories (e.g., 2-clause BSD for vcs-svn/*, LGPL2.1+ for xdiff/*). Signed-off-by: Richard Hansen rhan...@bbn.com --- I'm bringing this up because, to this layman's eyes, it seems like a potentially troublesome oversight. IIUC, one of the purposes of the Developer's Certificate of Origin is to make it easy for developers to declare which license covers a contribution. Requiring a license declaration protects the project and its users from copyright litigation. What happens if the file(s) being modified do not indicate which license applies to the file? Is there no license? Does it default to the main project license in COPYING? This lack of clarity makes me a bit nervous (law is already too nondeterministic for my liking), so I'd like to see a change that makes it explicit. Notes: * I am not a lawyer. (Maybe a lawyer should be consulted?) * This change might not be necessary. * This change might be wrong. * I hope I'm not just wasting everyone's time by bringing this up. Documentation/SubmittingPatches | 9 ++--- 1 file changed, 6 insertions(+), 3 deletions(-) diff --git a/Documentation/SubmittingPatches b/Documentation/SubmittingPatches index 7055576..c5ff744 100644 --- a/Documentation/SubmittingPatches +++ b/Documentation/SubmittingPatches @@ -227,13 +227,15 @@ the patch, which certifies that you wrote it or otherwise have the right to pass it on as a open-source patch. The rules are pretty simple: if you can certify the below: -Developer's Certificate of Origin 1.1 +Developer's Certificate of Origin 1.2 By making a contribution to this project, I certify that: (a) The contribution was created in whole or in part by me and I have the right to submit it under the open source license -indicated in the file; or +indicated in the file (or, if no license is indicated in +the file, the license in COPYING that accompanies the +file); or (b) The contribution is based upon previous work that, to the best of my knowledge, is covered under an appropriate open source @@ -241,7 +243,8 @@ pretty simple: if you can certify the below: work with modifications, whether created in whole or in part by me, under the same open source license (unless I am permitted to submit under a different license), as indicated -in the file; or +in the file (or, if no license is indicated in the file, +the license in COPYING that accompanies the file); or (c) The contribution was provided directly to me by some other person who certified (a), (b) or (c) and I have not modified -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH/RFC] Developer's Certificate of Origin: default to COPYING
On Thu, Sep 12, 2013 at 3:30 PM, Junio C Hamano gits...@pobox.com wrote: Linus, this is not limited to us, so I am bothering you; sorry about that. My instinct tells me that some competent lawyers at linux-foundation helped you with the wording of DCO, and we amateurs shouldn't be mucking with the text like this patch does at all, but just in case you might find it interesting... There were lawyers involved, yes. I'm not sure there is any actual confusion, because the fact is, lawyers aren't robots or programmers, and they have the human qualities of understanding implications. So I'm actually inclined to not change legal text unless a lawyer actually tells me that it's needed. Plus even if this change was needed, why would anybody point to COPYING. It's much better to just say the copyright license of the file, knowing that different projects have different rules about this all, and some projects mix files from different sources, where parts of the tree may be under different licenses that may be explained elsewhere.. Linus -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH/RFC] Developer's Certificate of Origin: default to COPYING
I certainly wouldn't recommend messing with the text of the DCO without first consulting some lawyers. There should also be some centralized coordination about any changes in the text and the version number. - Ted -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH/RFC] Developer's Certificate of Origin: default to COPYING
On 2013-09-12 18:44, Linus Torvalds wrote: On Thu, Sep 12, 2013 at 3:30 PM, Junio C Hamano gits...@pobox.com wrote: Linus, this is not limited to us, so I am bothering you; sorry about that. My instinct tells me that some competent lawyers at linux-foundation helped you with the wording of DCO, and we amateurs shouldn't be mucking with the text like this patch does at all, but just in case you might find it interesting... There were lawyers involved, yes. I'm not sure there is any actual confusion, because the fact is, lawyers aren't robots or programmers, and they have the human qualities of understanding implications. Well stated. :) So I'm actually inclined to not change legal text unless a lawyer actually tells me that it's needed. Is it worthwhile to poke a lawyer about this as a precaution? (If so, who?) Or do we wait for a motivating event? Plus even if this change was needed, why would anybody point to COPYING. It's much better to just say the copyright license of the file, knowing that different projects have different rules about this all, and some projects mix files from different sources, where parts of the tree may be under different licenses that may be explained elsewhere.. I agree that your phrasing is better. -Richard -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH/RFC] Developer's Certificate of Origin: default to COPYING
On Thu, Sep 12, 2013 at 4:15 PM, Richard Hansen rhan...@bbn.com wrote: Is it worthwhile to poke a lawyer about this as a precaution? (If so, who?) Or do we wait for a motivating event? I can poke the lawyer that was originally involved. If people know other lawyers, feel free to poke them too. Just ask them to be realistic, not go into some kind of super-anal lawyer mode where they go off on some what if thing. Note that one issue is that this is kind of like a license change, even if it's arguably just a clarification. I'd expect that a lawyer who is so anal that they think this wording needs change would also think that the DCO version number needs change and then spend half an hour (and $500) talking about how this only affects new sign-offs and how you'd want to make it very obvious how things have changed, Yadda yadda. IOW, my personal opinion is that if you get a lawyer that is _that_ interested in irrelevant details, you have much bigger problems than this particular wording. Lawyers do tend to be particular about wording, but in the end, they tend to also agree that intent matters. At least the good ones who have a case. Once they start talking about the meaning of the word 'is', you know they are just weaselwording and don't actually have any real argument. Linus -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH/RFC] Developer's Certificate of Origin: default to COPYING
On Thu, Sep 12, 2013 at 04:25:03PM -0700, Linus Torvalds wrote: On Thu, Sep 12, 2013 at 4:15 PM, Richard Hansen rhan...@bbn.com wrote: Is it worthwhile to poke a lawyer about this as a precaution? (If so, who?) Or do we wait for a motivating event? I can poke the lawyer that was originally involved. For what it's worth, there is an existing push to clarify the licensing terms for the DCO [1]. Involved parties include Luis Rodriguez, Richard Fontana, Bradley Kuhn, Mike Dolan, and Karen Copenhaver. Hopefully they'll have something to say after the New Orleans LinuxCon. The DCO licensing is not quite the same as changing the DCO text, but they're probably closely related ;). Cheers, Trevor [1]: http://thread.gmane.org/gmane.linux.kernel/1397613/focus=1400065 -- This email may be signed or encrypted with GnuPG (http://www.gnupg.org). For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy signature.asc Description: OpenPGP digital signature
