One of the drawbacks of software licensing with community projects -- although there are some (controversial) ways to sidestep this -- is that the license needs to be selected at the onset of the project, and you'd have to have everyone agree to that license or change the license.

If all the initial parties agree to use a FOSS license, they and all subsequent contributors under that license cannot complain that someone is actually employing that software per the terms of the license. A project might choose FOSS because they want to make sure the codebase only dies when it disappears from the last developer's disk.

If instead, the initial parties decided on some sort of profit-sharing license -- I don't know one of the top of my head -- then they and future contributors cannot complain if no business wants to use the software, either because FOSS competitors exist or because they don't like the profit split ratio in the license. If that ratio is fixed in the license, the project could die from lack of interest, since changing the license terms means everyone who contributed has to agree, so a single hardliner will doom the already-written code to obscurity.

The sidestep method -- which is what appears to have been used by Redis to do this relicensing to the SSPL -- is that all contributors must sign a separate agreement giving Redis Inc a stake in your contribution's copyright. This contributor agreement means any change to the Redis codebase -- since its inception? Idk -- has been dual-licensed: AGPL to everyone, and a special grant to Redis Inc who can then relicense your work to everyone under a new license.

Does the latter mean Redis Inc could one day switch to a fully-closed source license? Absolutely! That's why this mechanism is controversial, since it gives the legal entity of the project all the copyright powers, to level-up to FOSS or level-down to proprietary. Sure, you can still use the old code under the old license, but that's cold comfort and is exactly why hard forks of Redis are becoming popular right now.

In short, software projects have to lay out their priorities at the onset. If they want enduring code, that's their choice. If they want people to pitch in a fair share, that's fine too. But that choice entails tradeoffs, which they should have known from the start. Some mechanisms allow the flexibility to change priorities in the future, but it's a centralized, double-edge sword.