Two GitHub bots not talking to each other on a PR
github.com
github.com
They impose an unrequired additional legal burden on top of the standard software license.
They often require voluntary unpaid contributors to offer free support on indefinite term for software that they aren't supposed to maintain.
They are part of the same problem as the proliferation of custom T&Cs on online services (private parties creating whatever arbitrary set of binding rules they want on top of the standard law, assuming that they're so important that people are ok to waste half of their lives reading their legalese bullshit).
The difference is that, whilst there's no golden standard for a universal T&Cs that applies to all online services, we have one for software licenses.
That's the GPL, MIT, BSD or whatever license that basically every FOSS project slapts in their LICENSE.txt.
So, please, just stick to your LICENSE.txt, let your contributors stick to the basic common-sense rules written your CONTRIBUTING.md, and reserve a spot for CLAs in the graveyard of awful tech ideas that nobody should mourn.
I know what you mean with CLAs. They're very grabby. Not nice. Grabby aliens.
I wish it were different, and what you're saying is a nice idea, but if you're building or your company is building for profit (as we are), as well as for open then you can run into issues when accepting contribs from non employees.
The trouble is when a big customer wants to license or an investor wants to invest, they want to understand their risks, and that includes consideration of risks coming from ambiguous code ownership--or clear but problematic ownership: such as ownership that may interfere with whatever corporate license is being negotiated.
It's a similar reason to how when you are an employee of a software company, the company owns all rights to your contributions. One risk is you turn around later and want: attribution or ownership or decision making power, in a way that interferes with the company's or its customers interests. And when you don't get it, you sue. This is the sort of risk that CLAs are trying to protect against (same as those "we own everything you do when you work for us clauses" in contracts).
This stuff is not easy to figure out, and I had no idea at first. It took me 4 years to even settle on a license for my projects! Yes, I even tried writing my own because I was unsatisfied with the protections of the licenses I knew, and ignorant of other options, including, you guessed it, CLAs. The cacophony of insults for trying to use custom licenses was deafening. I had wandered into the Roman arena during a dog fight--and all the dogs had rabies. And spike collars! And lasers.
I agree none of this is ideal. I wish it were different, but I have not seen a solution for this beyond CLA so far. At a certain stage of growth, I want to pay everybody for every contribution. To me that seems completely fair, but the specifics of how that is figured out will have to be something for the future when we get there! :)
Fair enough, then whoever makes money out of the big customer/investor has also the burden of doing whatever engineers who make money out of software do - maintain it, patch it, provide support etc.
That's why many projects have a community edition (the core product, maintained by volunteers who only abide to the standard license of the software) and an enterprise edition (the one maintained by a business that makes money from shipping something that checks all the enterprise boxes out of the community project).
This model has worked for most of the businesses out there for at least the past three decades. Companies like Red Hat (the old one) made a lot of money out of it.
Inverting this business model means ending up in a situation where the enterprise side has the power of imposing an enterprise-like license to the FOSS community, instead of having a product released under a FOSS license that can also be forked into enterprise implementations - with their own custom EULAs, CLAs etc. that only apply to those enterprise implementations.
I don't think that is something that we should tolerate.
Can you share some examples of where inverting the business model leads to that? I'd be interested to peruse those projects on GitHub to understand more. I'm don't really grasp what you're saying about CLAs being evil or not something we should tolerate right now. :)
About the inversion of licensing - CLAs are basically inversions of the usual collaboration flow between community and enterprise. The community usually contributes to the FOSS project out of the terms of the FOSS license (which usually includes free redistribution, no warranty etc.). The enterprise maintains, well, an enterprise version of the project, that abides to its own licenses and all.
The community has never had to come in contact with the enterprise side so far. I can contribute to the CentOS trunk, without ever signing any agreement with Red Hat. If I need to contribute a patch directly to the Red Hat codebase, then it makes sense to sign a CLAs, otherwise it doesn't.
BTW - nice username, you actually work there?
This is just a repo with two bots turned on. Really confused why people are upvoting it.
I understand if you’re not concerned about this for your own projects, but I feel differently. Hope you can respect that.
To explain why people are voting it: I think it’s kind of a funny situation where you have these two bots and they’re both supposed to be helpful but the bots don’t actually cooperate with each other like the dependabot doesn’t sign the CLA I think it’s quite funny.
I understand if you don’t find funny, no worries! I guess other people appreciate it too. It’s OK if you don’t! The world is the diverse place. Hope you have a good day :)
One difference with your example is the use of the structure of collaboration of open source development.
I think I'm fine to include dependabot's contribs IF it will sign the CLA. So far it's refusing tho...hmmm, sus! haha :)