Live data from Hacker News

CLAs create different issues than making (small) open source contributions

utcc.utoronto.ca

51–60 of 70 posts

Re: CLAs create different issues than making (small) open source contributions

#51
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.)

Re: CLAs create different issues than making (small) open source contributions

#52
post #13

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?

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/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...

Re: CLAs create different issues than making (small) open source contributions

#53

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.)

What does a "signed-off-by: " do? Unless you use a "signed-the-agreement:" what is this trailer supposed to indicate?

Re: CLAs create different issues than making (small) open source contributions

#54
post #30

Earlier quoted context omitted.

FSF != FSFE.

I do hope very much. FSFE is the evil empire, the FSF the good one

It seems like you might have meant the opposite, based on your previous remark? Did you?

Re: CLAs create different issues than making (small) open source contributions

#55
post #46

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 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.

Re: CLAs create different issues than making (small) open source contributions

#56
post #49

Earlier quoted context omitted.

The CLA is really for corporate customers who give me bug fixes for their environments.

So then, you do want contributions.

No, but customers may have environments that I cannot reproduce.

Re: CLAs create different issues than making (small) open source contributions

#57
post #34
post #23

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

The solution to CLA proliferation is not the proliferation of CLA use, which is what your suggestion involves. If you want to solve CLA proliferation, it's as easy as not going out of your way to add a CLA to your project followed by insisting that people sign it. Let the strength of the license (and your faith in the choice of license) stand on its own.

Re: CLAs create different issues than making (small) open source contributions

#58
post #55
post #46

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…

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.

Re: CLAs create different issues than making (small) open source contributions

#59
post #58
post #55

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.

> the change is not copyrightable

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.

Re: CLAs create different issues than making (small) open source contributions

#60
post #52
post #13

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…

If you submit a PR of more than 3 lines changed, a bot asks you to e-sign the CAA before it can be merged.
Post reply on HN