5 ms·

"Whenever you add Content to a repository containing notice of a license, you license that Content under the same terms, and you agree that you have the right t

"Whenever you add Content to a repository containing notice of a license, you license that Content under the same terms, and you agree that you have the right to license that Content under those terms. If you have a separate agreement to license that Content under different terms, such as a contributor license agreement, that agreement will supersede." https://docs.github.com/en/site-policy/github-terms/github-terms-of-service#6-contributions-under-repository-license https://docs.github.com/en/site-policy/github-terms/github-t...

geenat 2y ago
Really good to see Github being pro-active to the benefit of the open source community.
- cxr 2y ago
  It's a stupid synthesis, though, just like the one from the article: > The repository is MIT-licensed, and clearly advertised as such, so it’s reasonable to expect all contributions are made under that license You don't have to assume anything, given the way pull requests work. It's not like it's a code snippet extracted from one of their comments on the bugtracker and then subsequently integrated upstream. They published something: their fork. Look at the repo the pull request is coming from—the one the requestor published. What is the license they published it under? Did they just dump a bunch of stuff online that says it's licensed under MIT? Yup. So if they have the rights to grant it to you, then you can use it under the MIT license. The only time this doesn't apply is when the contributor deletes their repo. The pull request turns into a patch merge request. But the repo doesn't have to remain available indefinitely. The mere fact that it was published under such-and-such license at some time and was available to you/whoever is sufficient.
  - manwe150 2y ago
    > So if they have the rights to grant it to you, then you can use it under the MIT license That seems rather the crux of the problem: did they have the right to upload that patch with the given license, or did they commit fraud first? Being able to see the LICENSE file still intact (which GitHub has promised you can do indefinitely for any PR branch even if the contributing repo got deleted) would not protect against that. The CLA doesn’t protect against it either, but apparently some companies think it is at least a useful additional legal barrier. IANAL and so not qualified to comment on whether such CLA is actually useful for the intended purpose I find it interesting to consider that open source existed for decades mailing patches (usually sans any license info) to a mailing list without legal trouble, and now that GitHub offers easy and complete traceability of the whole patch context this makes it to HN as a concern
    - anticorporate 2y ago
      It's a legitimate question. I'm generally opposed to CLAs and prefer DCOs (Developer Certificates of Origin) as that's the only thing I want an open source project to do when validating an individual's contribution - that is, to ensure that they have a right to make it, as opposed to forcing them to consent to other terms like potential future relicensings. https://en.wikipedia.org/wiki/Developer_Certificate_of_Origin https://en.wikipedia.org/wiki/Developer_Certificate_of_Origi... That said, the playing field is unequal between proprietary and open source projects. If I contribute open source code to a proprietary project, the odds of this being discovered and rectified are low, since the public doesn't get any right to audit closed-source software for the presence of copyleft code.
    - cxr 2y ago
      > The CLA doesn’t protect against it either, but apparently some companies think it is at least a useful additional legal barrier. IANAL and so not qualified to comment on whether such CLA is actually useful I'm not a lawyer, either, but that doesn't mean I'm not qualified to comment about whether it's useful. It's not. It's stupid, and they're wrong, whether they have a lawyer endorsing it or not. Don't let the Gell-Mann amnesia take root. There are just as many* cargo cult lawyers as there are cargo cult programmers. * this is a conservative estimate
Xylakant 2y ago
The problem with this is that it's an agreement between Github and the Contributor which the Maintainer cannot directly enforce. The maintainer can point to it when they get sued, but they would likely need to get Github to enforce it.

geenat 2y ago

Really good to see Github being pro-active to the benefit of the open source community.

cxr 2y ago
It's a stupid synthesis, though, just like the one from the article: > The repository is MIT-licensed, and clearly advertised as such, so it’s reasonable to expect all contributions are made under that license You don't have to assume anything, given the way pull requests work. It's not like it's a code snippet extracted from one of their comments on the bugtracker and then subsequently integrated upstream. They published something: their fork. Look at the repo the pull request is coming from—the one the requestor published. What is the license they published it under? Did they just dump a bunch of stuff online that says it's licensed under MIT? Yup. So if they have the rights to grant it to you, then you can use it under the MIT license. The only time this doesn't apply is when the contributor deletes their repo. The pull request turns into a patch merge request. But the repo doesn't have to remain available indefinitely. The mere fact that it was published under such-and-such license at some time and was available to you/whoever is sufficient.
- manwe150 2y ago
  > So if they have the rights to grant it to you, then you can use it under the MIT license That seems rather the crux of the problem: did they have the right to upload that patch with the given license, or did they commit fraud first? Being able to see the LICENSE file still intact (which GitHub has promised you can do indefinitely for any PR branch even if the contributing repo got deleted) would not protect against that. The CLA doesn’t protect against it either, but apparently some companies think it is at least a useful additional legal barrier. IANAL and so not qualified to comment on whether such CLA is actually useful for the intended purpose I find it interesting to consider that open source existed for decades mailing patches (usually sans any license info) to a mailing list without legal trouble, and now that GitHub offers easy and complete traceability of the whole patch context this makes it to HN as a concern
  - anticorporate 2y ago
    It's a legitimate question. I'm generally opposed to CLAs and prefer DCOs (Developer Certificates of Origin) as that's the only thing I want an open source project to do when validating an individual's contribution - that is, to ensure that they have a right to make it, as opposed to forcing them to consent to other terms like potential future relicensings. https://en.wikipedia.org/wiki/Developer_Certificate_of_Origin https://en.wikipedia.org/wiki/Developer_Certificate_of_Origi... That said, the playing field is unequal between proprietary and open source projects. If I contribute open source code to a proprietary project, the odds of this being discovered and rectified are low, since the public doesn't get any right to audit closed-source software for the presence of copyleft code.
  - cxr 2y ago
    > The CLA doesn’t protect against it either, but apparently some companies think it is at least a useful additional legal barrier. IANAL and so not qualified to comment on whether such CLA is actually useful I'm not a lawyer, either, but that doesn't mean I'm not qualified to comment about whether it's useful. It's not. It's stupid, and they're wrong, whether they have a lawyer endorsing it or not. Don't let the Gell-Mann amnesia take root. There are just as many* cargo cult lawyers as there are cargo cult programmers. * this is a conservative estimate

Xylakant 2y ago

The problem with this is that it's an agreement between Github and the Contributor which the Maintainer cannot directly enforce. The maintainer can point to it when they get sued, but they would likely need to get Github to enforce it.