In The Spirit Of The License
In recent years a few major open source project have changed their original permissive license to a business oriented one. They did this after having had plenty of success and contributions specifically because they had that permissive licensing to begin with.
The most recent one is WordPress changing their trademarks only to force a competitor, of which they owned a share in the past, to pay a ransom for using their open source CMS. Other examples include MongoDB, ElasticSearch and Redis (more recently).
The story goes likes this: A company builds an open source project and gives it to the community. They build a service around the open source project. It picks-up interests and other people start contributing. The interest grows and other companies start providing competing services for these technologies. The original company gets mad and changes the license from a permissive one to a strict one forcing other companies to cease offering competing services.
At least this is what they expect happen but it is not what actually happens. A fork on the previous commit to the license changing still makes the technology legal to use and provide services for.
If you have built a service business around a technology you most surely have a pretty good understanding of the internals. Even more if you have had a member of your team actively contribute to the project. The beginning might be a bit rough tho but in time you can start building and modifying the original project tailored to your own needs. To not speak of the big companies with plenty of resources to rebuilt the entire thing the way they wanted to do but never had a good excuse to do so. This is the case of ElasticSearch changing their license just to restrict AWS from providing hosting services and they ended up creating the OpenSearch project within the AWS ecosystem. And they made it available under Apache License 2.0
How arrogant does one have to be in order to think that they are the only one capable of doing a project? How little foresight one has to have to not see that there might be people that will build an alternative just out of spite?
What's even more surprising is that the same people who write code do not understand that the law is the same but for providing a set of rules for interpersonal relations. In the same fashion as code, the more lines the Terms & Conditions have the more exceptions it will produce and harder it will be to handle all of them in practice. Unless, in the same fashion as in code, you just handle the few exceptions that bother you and let the end user figure it out as they happen in production.
There is a reason why the expression "In the spirit of the law" exists and it is to remind all the subjects involved how the law originated in order to stop the endless use of rhetoric to undermine its significance and importance.
The only reason to use open source software is because of its permissive licensing. Other than that it has not value. The most popular and well maintained projects are so generic and therefore so bloated to meet all the requested use cases that it takes a huge toll on performance. And on a large scale of time everything becomes everything. Heck, even strict project like golang are implementing more and more features that go against the original idea behind the project. Each subsequent new feature has a little less impact than the previous one. Take range functions for example, it provides no new functionality and at the same time makes the code less readable. It's seems to be the case that any project that does not aggressively implement user requests as a feature factory it is eagerly dismissed as a dead project.
To use any open source code is a wonderful experience. To clone a repository, run a few commands and have a complete setup for your project. In just a few minutes you have the ability to start writing just the code necessary for your project. And it's not only the main project but all the other small packages that create a rich ecosystem and people building upon other people projects. In the same fashion that Apple once said: "There is an app for that!", the open source community can say: "There is a solution for that!".
The source code of large open source project serve the purpose of teaching how to write actual code that goes in production. You can read a million articles, read a thousand books on design patterns, architecture and other boring stuff that will almost never apply into production. The isolated example in the pristine context of the book does not stand in the strong winds and turbulent waters of delivering working software to production as a team and all the compromises along the way that it takes to do so.
Now if you were to add a money component to the any of the wildly permissive license out there, even to the MIT license, and so much as to ask for let's say 0.1% of gross revenue after you hit your first $10.000.000 in gross revenue it would change the entire thing. Even tho the majority of the project never even make a sale, it would make the open source project to never be considered for anything that could remotely be monetized, ever.
And yet the license change still do not address the problem that the project owners want to address: to not have big corps make money off their backs. This sounds better on paper than it is in reality. In the worst case scenario for the big corps, they will throw enough bodies and plenty of resources at the problem until the problem is solved. OracleDB is clear example of this.
The situation is tough only for the small players who don't have the bodies nor the resources and in many cases not even the expertise to implement such a solution. How would the world would look like without Git, without Docker, without K8S, without the Unix kernel. Imagine having to pay for Windows Server license as a small company while some big company gets to deploy a fleet of Unix based instances fully managed by K8S with every app running isolated from one another and rollbacks are as easy as returning to a previous commit. You would have zero chances of beating them no matter the market, an existing one or a new one.
If you want to write open source code for everyone then do so, if not just start a business. In any case, be upfront with your conditions and expectations.