51–60 of 73 posts
> The contribution bot asks for confirmation the code change is copyright-free A confirmation is simply unnecessary. Can't it work like, writing this somewhere that says, by creating a pull request, you agree all your code and the discussions around the pull request is now copyright free? Saves everybody time and avoid hassles like this. The other side of this is I get very annoyed by CLAs -- there have been a number…
Maybe there is a way to do it without one, but I couldn't figure it out.
The barrier for that sort of thing is really low, but copyright does have an exemption for stuff like that.
(Upd: Looked at the PR in other comments; yeah I don't think the null guard meets copyrightability, but I Am Not A Lawyer. The attached test case might be more dubious.)
I don't like them and won't contribute to projects with them but isn't this the exact point of a CLA[1]? A textfile in the repo seems a lot easier to track and audit than PR comments and a bot to chase people. 1. https://en.m.wikipedia.org/wiki/Contributor_License_Agreemen...
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.
The reality is that without a CLA, copyright enforcement tends to turn into a complete mess. To be clear - that can absolutely be the point; a completely unenforceable copyright that's still enough of a mess to scare off violators can have it's uses; the Kernel jumps to mind. Linus and Greg have both been open about the fact that the license is there to encourage people to contribute as a carrot, not there as a stick to beat them over the head with. Explaining how the license works and why they'd really appreciate cooperation is much more useful for the LKML than it would be to keep a bunch of lawyers on standby and the fractured license helps achieve that goal.
They're often used by corporations to rugpull a license change, but the original purpose of a CLA is just to ensure that there's one entity in control of the licenses, which is more useful if an entity prefers the stick approach to compliance. (Which the FSF I would say absolutely lands under by-the-by.)
Earlier quoted context omitted.
That's more the risk than the purpose. Some people do CLA's for that purpose, but sometimes it really is about having a paper trail that the software is open source, or to make it easier to sue people who violate the license.
A DCO [1] would serve that purpose better. It's possible that the desire to have the flexibility to change the license at some point in the future is initially well-intentioned (for example you may start out as GPL, but want the option to change to Apache 2.0 later), so having a CLA doesn't necessarily imply they plan on doing a rug pull. And of course there is probably also some cargo cult of using a CLA because tha…
The DCO is also very patch oriented, rather than contributor oriented, which only works if your workflow has more contributors than patches (which isn't how most FOSS projects are organized; you usually have only a few contributors, who submit patches.)
Finally, the DCO was put in place to resolve someone being annoying about the licenses rather than existing to unify the copyright of the Kernel behind one entity.
Earlier quoted context omitted.
Python has a CLA that allows the PSF board to relicense the code to "any other open source license approved by unanimous vote".
Legally speaking, once they own the copyright, is there anything stopping the PSF from selling out and changing their policy to permit proprietary licensing? 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.
Text from their contributor agreement:
> PSF understands and agrees that Contributor retains copyright in its Contributions.
Earlier quoted context omitted.
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…
> 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…
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.
"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-t...