https://developercertificate.org
(We have a GitHub action that verifies this, based on another action, based on something by Probot. Ours has been modified to allow automatic DCO certification for people from the company.)
51–60 of 70 posts
https://developercertificate.org
(We have a GitHub action that verifies this, based on another action, based on something by Probot. Ours has been modified to allow automatic DCO certification for people from the company.)
Earlier quoted context omitted.
As soon as I see a CLA I'm turned off even using a piece of FOSS software. I get it's usually just the lawyers protecting the company just in case a contributor tries something dodgy in the future. Out of principle however, I resent the broad assignment of copyright and granting them the right to relicense. Of course I expect most of these projects would never exercise that right, but the mere fact that they _could_…
I have a CAA on my GPL project so that I have the right to start releasing it as MIT, that is, more Free. Also so I can dual-license it to a corporation and make a modicum of money from the software that is 98% my work. I absolutely never intend to make future versions non-free (and I don't even have the right to make already released versions non-free). Do you find this disturbing?
https://github.com/saulpw/visidata/blob/develop/CONTRIBUTING...
Also take a look at GitHub's ToS, which explicitly states that "inbound=outbound" is the default. I don't think you can expect people to hunt down your little notice when there is a site-wide default. https://docs.github.com/en/site-policy/github-terms/github-t...
For the open source projects I manage related to $DAYJOB, we require DCO signoffs using the `Signed-off-by` signature in commits. https://developercertificate.org (We have a GitHub action that verifies this, based on another action, based on something by Probot. Ours has been modified to allow automatic DCO certification for people from the company.)
HN is somehow always timely. Currently, these folks expect me to sign a CLA for a one-byte change to their README: https://github.com/gravitl/netmaker/pull/2516
There is so little that you stand to gain by agreeing to the CLA (and so much downside for them if they reject it and keep the status quo) that the best thing would be to say no.
And I hope that if they do keep it as-is and then someone comes along later and makes the fix, you hound them about violating your IP and cite their comment "we do not have the rights" as prima facie evidence. Make CLA worshippers bite the bullet on their goofy beliefs.
Earlier quoted context omitted.
I'm aware of the following: https://harmonyagreements.org/ Still, CLAs are a barrier on their own already. Standardizing them doesn't help. Plus as another commenter mentioned: sometimes a standard CLA is used but then various bits aren't filled in.
Standardizing CLA's helps the same way standardizing software licenses helps prevent license proliferation [1]. Code hosting websites, like GitHub, should provide a mechanism for registered users to electronically sign a CLA from their web interface. No hassle, no unfilled bits, and you've got a 3rd party (e.g. GitHub) notarizing the contract. [1] https://en.wikipedia.org/wiki/License_proliferation
HN is somehow always timely. Currently, these folks expect me to sign a CLA for a one-byte change to their README: https://github.com/gravitl/netmaker/pull/2516
This is amazing. (Note for the reader: look at the change https://github.com/gravitl/netmaker/pull/2516/commits/196b1f... >). There is so little that you stand to gain by agreeing to the CLA (and so much downside for them if they reject it and keep the status quo) that the best thing would be to say no. And I hope that if they do keep it as-is and then someone comes along later and makes the fix, you hound them about…
Luckily, as I wrote, the change is not copyrightable and no one, including myself or my employer, can claim copyright ownership over it.
Earlier quoted context omitted.
This is amazing. (Note for the reader: look at the change https://github.com/gravitl/netmaker/pull/2516/commits/196b1f... >). There is so little that you stand to gain by agreeing to the CLA (and so much downside for them if they reject it and keep the status quo) that the best thing would be to say no. And I hope that if they do keep it as-is and then someone comes along later and makes the fix, you hound them about…
I cannot sign the CLA since per its own terms, I would have to get written permission from my employer. Luckily, as I wrote, the change is not copyrightable and no one, including myself or my employer, can claim copyright ownership over it.
Right.
> no one, including myself or my employer, can claim copyright ownership over it
People can claim anything they want. Whether they're correct is the thing. I'm suggesting that, since they've articulated a belief that they can't use it without an explicit CLA, you go ahead and yes-and them and play it out both for comedy's sake and the greater good.
Earlier quoted context omitted.
I have a CAA on my GPL project so that I have the right to start releasing it as MIT, that is, more Free. Also so I can dual-license it to a corporation and make a modicum of money from the software that is 98% my work. I absolutely never intend to make future versions non-free (and I don't even have the right to make already released versions non-free). Do you find this disturbing?
You seem to have a single line at the bottom of your CONTRIBUTING.md stating that contributors assign copyright to you. I doubt that this is worth anything legally. You have probably received and merged many contributions whose author didn't have the right to assign it to you, and having put no effort in checking that, you would probably be the one found in the wrong. https://github.com/saulpw/visidata/blob/develop/C…