4 ms·

Despite the assumption of some newer open-source developers that sending a pull request on GitHub “automatically” licenses the contribution for distribution on

Despite the assumption of some newer open-source developers that sending a pull request on GitHub “automatically” licenses the contribution for distribution on the terms of the project’s existing license—what Richard Fontana of Red Hat calls “inbound=outbound”—United States law doesn’t recognize any such rule. Strong copyright protection, not permissive licensing, is the default. That isn't quite what I mean by "inbound=outbound". Rather, inbound=outbound is a contribution governance rule under which inbound contributions, say a pull request for a GitHub-hosted project, are deemed to be licensed under the applicable outbound license of the project. This is, in fact, the rule under which most open source projects have operated since time immemorial. The DCO is one way of making inbound=outbound more explicit, and I increasingly think one that should be encouraged (if only to combat the practice of using CLAs and the like). But under the right circumstances it works even where the contribution is not explicitly licensed (I think this is what Kyle may be questioning). There are other ways besides the DCO of creating greater certainty, or the appearance of greater certainty, around the inbound licensing act, such as PieterH's suggestion of using a copyleft license like the MPL, or the suggestion of using the Apache License 2.0 (whose section 5 states an inbound=outbound rule as a kind of condition of the outbound license grant).

loeg 10y ago
What does DCO mean in this context?
- richardfontana 10y ago
  The Developer Certificate of Origin. It's the 'Signed-off-by:' process introduced by the Linux kernel project. http://developercertificate.org/ http://developercertificate.org/ https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/SubmittingPatches?id=refs/tags/v4.8-rc7#n409 https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.... I particularly recommend the presentations and writings of James Bottomley on the DCO, e.g.: http://www.hansenpartnership.com/FOSDEM-DCO-2016/#/begin http://www.hansenpartnership.com/FOSDEM-DCO-2016/#/begin
  - loeg 10y ago
    Thanks!
- no_protocol 10y ago
  Developer's Certificate of Origin, see the last paragraph of the section about the copyright notice.
wongarsu 10y ago
But a pull request on github invariably come from a branch that has the same license file. Before you can even make a pull request you have to publish your changes, and that version is clearly licensed by the license file. A better example would be emailed patch sets, which are still popular in some projects.
- richardfontana 10y ago
  Good point about github pull requests, I've made that argument as well recently. It's somewhat akin to Pieter's point about MPL. Github gets criticized for the phenomenon of 'POSS' (post-open-source software, https://en.wikipedia.org/wiki/Post_Open_Source https://en.wikipedia.org/wiki/Post_Open_Source), but there's a sense in which the Github workflow has provided greater clarity around licensing of diverse-contributor projects that are sufficiently explicit about outbound licensing.
kemitchell 10y ago
Thanks for this comment! I'm glad somebody told me this was on HN. It's a problem with the sentence, which I'll correct shortly. I wanted to mention inbound=outbound, and tried to do so in passing, in the middle of a sentence performing other work. It ends up reading like inbound=outbound is the assumption about GitHub and fora like it, rather than the governance idea of same terms in and out. I definitely don't want to dilute the term or the idea as you've developed it! I _do_ question whether US courts will reliably imply inbound=outbound when the contributor is silent on license. There will be circumstantial and perhaps specific conduct evidence for abandonment, estoppel, or both. But that's the same line of thinking that applies to unlicensed projects. Not good enough. For what it's worth, I support the idea of the DCO, but never recommend it. I'd like to think my criticisms are best summed up in the alternative I've been working on: https://github.com/berneout/berneout-pledge https://github.com/berneout/berneout-pledge The last paragraphs in that README are the most important. "CLA or not to CLA" is primarily a culture issue. It needs to be solved as one.
- tzs 10y ago
  It was an excellent article. I'd have liked to have seen more on sublicensing vs. direct licensing, but that's probably a big enough subject that it deserves its own article. In particular, I don't think there's been enough discussion on what this means in the case where the copyright owner decides that they no longer wish to have their code distributed under the original license. If I distribute my code under a license using the direct model, and subsequently announce that I'm no longer granting licenses, and you (who obtained my code before I made that announcement) distribute a copy, I think there is little question you are OK. You've got your direct license from me. But what about the person you distribute to? I think they would be OK to use it, but I'm not sure they could redistribute. Maybe someone could make an argument involving third party beneficiaries that could force me to license your recipients under the original license, but that's going to be an ugly fight. If I had originally used a license that allowed sublicensing, wouldn't things be a lot cleaner? People you distribute to after I stop issuing new licenses would simply get their license from you via you exercising the sublicensing right I gave you. Some free/open licenses now say in the license text that they are irrevocable, which would seem to address this problem, but thinking about it more I'm not so sure. If my original license using the direct model said it was irrevocable, does that really mean I have to keep granting new direct licenses to anyone who obtains the software from a prior licensee, or does it just mean that I cannot cancel the license of someone once they obtain a license from me?

loeg 10y ago

What does DCO mean in this context?

richardfontana 10y ago
The Developer Certificate of Origin. It's the 'Signed-off-by:' process introduced by the Linux kernel project. http://developercertificate.org/ http://developercertificate.org/ https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/SubmittingPatches?id=refs/tags/v4.8-rc7#n409 https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.... I particularly recommend the presentations and writings of James Bottomley on the DCO, e.g.: http://www.hansenpartnership.com/FOSDEM-DCO-2016/#/begin http://www.hansenpartnership.com/FOSDEM-DCO-2016/#/begin
- loeg 10y ago
  Thanks!
no_protocol 10y ago
Developer's Certificate of Origin, see the last paragraph of the section about the copyright notice.

wongarsu 10y ago

But a pull request on github invariably come from a branch that has the same license file. Before you can even make a pull request you have to publish your changes, and that version is clearly licensed by the license file. A better example would be emailed patch sets, which are still popular in some projects.

richardfontana 10y ago
Good point about github pull requests, I've made that argument as well recently. It's somewhat akin to Pieter's point about MPL. Github gets criticized for the phenomenon of 'POSS' (post-open-source software, https://en.wikipedia.org/wiki/Post_Open_Source https://en.wikipedia.org/wiki/Post_Open_Source), but there's a sense in which the Github workflow has provided greater clarity around licensing of diverse-contributor projects that are sufficiently explicit about outbound licensing.

kemitchell 10y ago

Thanks for this comment! I'm glad somebody told me this was on HN. It's a problem with the sentence, which I'll correct shortly. I wanted to mention inbound=outbound, and tried to do so in passing, in the middle of a sentence performing other work. It ends up reading like inbound=outbound is the assumption about GitHub and fora like it, rather than the governance idea of same terms in and out. I definitely don't want to dilute the term or the idea as you've developed it! I _do_ question whether US courts will reliably imply inbound=outbound when the contributor is silent on license. There will be circumstantial and perhaps specific conduct evidence for abandonment, estoppel, or both. But that's the same line of thinking that applies to unlicensed projects. Not good enough. For what it's worth, I support the idea of the DCO, but never recommend it. I'd like to think my criticisms are best summed up in the alternative I've been working on: https://github.com/berneout/berneout-pledge https://github.com/berneout/berneout-pledge The last paragraphs in that README are the most important. "CLA or not to CLA" is primarily a culture issue. It needs to be solved as one.

tzs 10y ago
It was an excellent article. I'd have liked to have seen more on sublicensing vs. direct licensing, but that's probably a big enough subject that it deserves its own article. In particular, I don't think there's been enough discussion on what this means in the case where the copyright owner decides that they no longer wish to have their code distributed under the original license. If I distribute my code under a license using the direct model, and subsequently announce that I'm no longer granting licenses, and you (who obtained my code before I made that announcement) distribute a copy, I think there is little question you are OK. You've got your direct license from me. But what about the person you distribute to? I think they would be OK to use it, but I'm not sure they could redistribute. Maybe someone could make an argument involving third party beneficiaries that could force me to license your recipients under the original license, but that's going to be an ugly fight. If I had originally used a license that allowed sublicensing, wouldn't things be a lot cleaner? People you distribute to after I stop issuing new licenses would simply get their license from you via you exercising the sublicensing right I gave you. Some free/open licenses now say in the license text that they are irrevocable, which would seem to address this problem, but thinking about it more I'm not so sure. If my original license using the direct model said it was irrevocable, does that really mean I have to keep granting new direct licenses to anyone who obtains the software from a prior licensee, or does it just mean that I cannot cancel the license of someone once they obtain a license from me?