Missing open-source contributor presents a dilemma when accepting their PR
41–50 of 73 posts
Re: Missing open-source contributor presents a dilemma when accepting their PR
#42I’m not a lawyer at all. What i feel is that the existence of the copyright assignment bot makes this decision worse. I think it is perfectly reasonable to say “you contributed to the project knowing that the project is licensed X, therefore we can assume that you are ok with your contribution being under the same license and we just merge it”. Not saying that it is wise legally, but it feels to be a coherent theory…
Re: Missing open-source contributor presents a dilemma when accepting their PR
#43You actually don't use their code. Understand what is being fixed and write it yourself.
Re: Missing open-source contributor presents a dilemma when accepting their PR
#44From a logical standpoint, if someone makes a pull request to an open source project, it should be safe to assume they are ok with it being distributed under the current license of the project they are contributing to. But copyright law isn't always logical.
Re: Missing open-source contributor presents a dilemma when accepting their PR
#45Earlier quoted context omitted.
Really good to see Github being pro-active to the benefit of the open source community.
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 publ…
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
Re: Missing open-source contributor presents a dilemma when accepting their PR
#46It's already part of github TOS as quoted in another comment, so you're just creating repetition hurdles (which won't save you anyway in case of real trouble)
Re: Missing open-source contributor presents a dilemma when accepting their PR
#47Re: Missing open-source contributor presents a dilemma when accepting their PR
#485. Remove the annoying bot and merge it anyway. It's already part of github TOS as quoted in another comment, so you're just creating repetition hurdles (which won't save you anyway in case of real trouble)
Re: Missing open-source contributor presents a dilemma when accepting their PR
#49Re: Missing open-source contributor presents a dilemma when accepting their PR
#50Earlier quoted context omitted.
No. The purpose of a CLA is so that the owner of the project can use the code in a commercial product that might not comply with the OSS license (particularly if that license is a copyleft licence such as GPL, AGPL, or MPL) and/or they can change the license more easily.
Python has a CLA that allows the PSF board to relicense the code to "any other open source license approved by unanimous vote".
I have this same concern with GNU. I can imagine a future where some key figures have died or retired and the new org sells out and changes the license to something RMS never would have agreed to.