You can't have your cake and eat it too. If you want usage, you can make it MIT and then suffer while they capitalize your code (as they are with in their rights to do), or if you want protection but low usage, make it AGPL or proprietary even. I don't really see a scenario where you have high usage, high protection and also high profit from you selling your product, unless you are good at marketing and selling your product.
- high usage - high protection - high profit
What's the argument that OSS software (which you could use for free indefinitely until you gain profitability) is somehow not capable of the same?
> - high usage - high protection - high profit
> What's the argument that OSS software (which you could use for free indefinitely until you gain profitability) is somehow not capable of the same?
Software that meets those criteria also has an organization that spends quite a lot on sales and marketing. Stimulation of usage and extraction of revenue doesn't happen on its own.
More explicitly, if an already-profitable organization can't use the software without paying on day zero, quite a lot of effort has to be expended to get them to make the leap, hence the long enterprise sales cycle. You can do it with just marketing if you keep the purchase price low (ie. below what a department manager is allowed to spend using a corporate credit card).
Open source can circumvent this to an extent, but to do so it has to allow businesses to use the software for free, and convert a percentage of those users to paying voluntarily.
Whether the mechanism of conversion is consulting and customization services, hosting services, support services, dual licensing, an 'enterprise' version with specific features, or something else is immaterial, they are never just paying for exactly what they were getting for free. The closest a business will come to that is employing developers to work on the open-source software, or at least allowing employees to work on the software during work hours.
The specific licensing-only approach you're outlining will only work in a very narrow case: A new unprofitable company starts using the software for free, and starts paying once they cross over to profitability (at which point they might decide to switch to using something else, instead). Note that there are some very large VC-fueled companies that have yet to be profitable. Convincing an already profitable business to pay at the outset just can't be done without the aforementioned marketing and sales.
Going open source is one of the ways to increase your chances of increased usage.
It is very much the Silicon Valley mentality that all value is added by that company and that no suppliers should make any profit.
Cynically, open source libraries need to use the err, hook-and-sinker approach?
The common terminology is “bait and switch”. Also very much Silicon Valley. Apple for example likes to become a critical customer for any supplier, then use their leverage to squeeze them.
Besides, it would have to be a lot more formal; another commenter mentioned the Unreal Engine, which states something to the tune of "free to use until you earn over X, then you pay us Y% of your revenue".
Cynically, open source libraries need to use the err, hook-and-sinker approach? Be really good at bootstrapping a company or part thereof, then when they have buy-in, start charging. It's what Unreal and (I think?) Unity do, it's what Slack did (really successfully, in a lot of places where it was introduced it was snuck in the back door by employees, used for a couple of months until the restrictions became too much, then the company started to pay for it; I've never seen 'grassroots' software deployment like that before and I'm impressed).
But it'll be difficult to pull off fully without the software being as-a-service or DRM things.
I wonder if the package manager systems could play a role in that. Require you to register your application at e.g. NPM, then every time an `npm install` is done, keep track of it. If usage does not decrease, start charging for things.
One could also consider an alternative, compatible package manager; an open source publisher could opt to only push to and promote that one. The package manager charges for use, and pays package maintainers relative to usage.