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