It stops companies from building high-revenue products for free, while not being as scary as AGPL/LGPL from the business perspective, and completely unrestricted for everyone else (despite not being technically an open-source license).
It's pretty much a standard non-free commercial license, which exact wording will matter only to purchasing department of your customers. It will be inconsequential to the broader open source community. Literally thousands of those exist and the specific wording matters very little.
If you frame the licensing space as for either personal or commercial use, perhaps your point of view makes sense, but this is not a useful framing for most people, and it is specifically not something the open source community cares about.
If you wish to keep leverage over others then you do not wish to have them compete with you on the same product. That is a valid position to have, but it is squarely on the non-free part of the licensing spectrum. You don't want to play within the open source community and they don't want to play with you. All anyone owe others is to make that clear.
They were attacked by OSI zealots every time because it's not real open source. Which is true, but the unsaid - or well, only sometimes mentioned - other half is that these open source enthusiasts would you rather have a bog standard all-rights-reserved commercial licence than a relatively open licence without the four freedoms!
I can't claim to read other people's thoughts, but my hunch is that this happens because it's too "close" to an open source licence so they view it as competition, while they view commercial software as either a straightforward enemy or they don't care about it whatsoever.
The history aside, this approach just makes the open source community more and more irrelevant each day, especially with the advent of "vibecode your own dependencies up". The 4 freedoms come from a place where they were about users, but gigantic corporations have shoehorned themselves into being users, and instead of the community defending against it, they think the freedom to exploit the maintainers' work while contributing nothing back is more important than keeping the commons free and shared. :P
Only siths think in absolutes.
From a pure engineering reliability perspective, coupling your technology choice to your vendor gives that vendor too much leverage (as we've seen with, for example, VMware).
This isn't about defending the big companies at all. It's about defending the right of hosting providers to compete on hosting a variety of software. In the alternative world of entirely commercial licenses, or entirely BUSL-styled licenses, you would be shackled to the specific vendors that happened to create the technology that you wanted to leverage. This is a scenario where the customer invariably loses.
FOSS is a great answer to the first few questions, but it fails at the last one. As a user, yes, I would prefer a cloud-protection license, if it means that software will still be developed in a few years time. It's not like I want to use this software to compete with the author, I'm happy not to be allowed to do that.
Let's not get everything mixed up here - I singled out BUSL exactly because it does not prevent competing services, especially at small scale. In fact it would encourage small business and individual usage vs big cloud providers. It also has a conversion clause, so worst case scenario you have a slightly outdated MIT-licensed release to pick up from.
The EUPL the author mentions, the AGPL and others are the ones that directly prevent competing services.
That said, indeed it might not be an ideal choice for that kind of cloud-hosted software if you want to maximize adoption.
To support sibling comment: no it doesn't?
But your point about the revenue cut off in the BUSL is worthwhile (assuming we're talking about a licensor that is leveraging the additional use grant). I just disagree that it's a remedy because it basically punishes a business for being successful, by changing the rules upon which it was built. I'd be very curious to hear of anybody who has licensed software under the BUSL and has ended up getting a license from companies that meet those revenue thresholds.
It's worth noting that the BUSL, by default, with no additional use grant, prohibits the use of the software in production. So I actually think you have the two licenses reversed. The BUSL prohibits production use and competing services by default unless an additional use grant is specified and then it is only allowed under the revenue threshold specified in the additional use grant.
The AGPL has no prohibition whatsoever on the deployment of competing services.
> You may make production use of the Licensed Work, provided Your use does not include offering the Licensed Work to third parties on a hosted or embedded basis in order to compete with HashiCorp’s paid version(s) of the Licensed Work.
Or, for a revenue threshold:
> You may make production use of the Licensed Work, provided that your use is solely for an application or system developed or operated by an entity (including its affiliates) with total annual gross revenues of less than $10,000,000 USD.
That is the whole point - you can define your own limits for commercial usage, while keeping the rest of the license text unchanged.
The AGPL's "viral" property inhibits competition without prohibiting it - companies are just scared of accidentally becoming liable to publish private software sources. As far as I know, that's the reason it is banned at Google, Apple and other major companies [1].
That didn't stop AWS though, which is why we now have SSPL and the BSL.
[1] https://opensource.google/documentation/reference/using/agpl...
1. BUSL does not allow production use. Additional Use Grant (optional) is necessary to allow this, and is typcially accompanied by a revenue limit, setting a trap for any business that attempts to use it by changing the rules as they become more successful.
2. The AGPL does allow production use, by default, forever, but requires you publish associated source code when providing the service.
Only one of these licenses bans production use, and that's the BUSL. It can be modified to allow it under certain circumstances, but your original statement, that BUSL allows production use and AGPL prohibits it, is exactly reversed.
I find this much simpler to understand than AGPL/LGPL or the linked EUPL.
HashiCorp switched to BUSL license for their products/tools when they already had substantial market share, and they still faced MPL-licensed forks (Terraform -> OpenTofu, Vault -> OpenBao). It will be interesting to see in a few years if those tools notably cut into their share.
I'm not sure a new tool with a BUSL license will get adoption as easily.
- BUSL is OSI-approved and listed in SPDX, so corporate lawyers won't be scared away by it: https://spdx.org/licenses/BUSL-1.1.html
- With BUSL the restriction is revenue-based. You can still create competing products, but would have to pay a licensing fee.
Of course it isn‘t.
Debian FSG compatible No
FSF approved No
OSI approved No
GPL compatible No
Copyleft No