Open Core and BSL License Traps to Watch For
Open core and BSL license traps can lock you in as hard as any SaaS. How to read software licenses so self-hosting an open tool does not turn into a bill.
Self-hosting an open-source tool feels like the ownership move. Sometimes it is a trap with an open-source label. Open core and source-available licenses like the BSL and SSPL are built to look free while keeping the parts you actually need on the paid side of a wall, or forbidding the uses you actually have. You install the community edition, build on it, and discover the feature you need is enterprise-only, or that the license quietly bans you from doing the thing you were planning. Owning your stack means reading the license before you commit, not after you are locked in.
Why an open license can still trap you
The word open is doing a lot of work in marketing that it does not do in the license file. Three patterns show up again and again.
Open core. The base is genuinely open, but the features that matter at scale, like clustering, SSO, audit logs, or access controls, are locked behind an enterprise license. You self-host the free part, grow, hit a wall, and now you are paying anyway, except you also carry all the self-hosting work. You got the worst of both worlds.
Source-available. The code is readable but the license is not open source. The BSL, for example, often forbids using the software to offer a competing service and converts to an open license only after a few years. That may be fine for you or may kill your use case, and you cannot tell without reading it.
Rug-pull relicensing. A tool ships under a real open license, builds a community, then relicenses to something restrictive once enough people depend on it. If your dependency does this, your options are stay on the old frozen version, pay, or migrate. This is the same acquisition-style risk covered in what happens when your vendor gets acquired, just delivered through a license change instead of a purchase.
How to read a software license before you commit
You do not need a lawyer for the first pass. You need to answer four questions.
Can I use it for my actual purpose? Some source-available licenses ban offering the software as a service, or ban commercial use above a threshold. If you are building a product on top of it, this is the question that matters most.
What is actually in the free tier? Find the feature comparison and assume you will eventually need the things on the paid side. If the features you will predictably need at scale are all enterprise-only, this is open core lock-in wearing an open badge. Price it now, not at renewal.
Can the license change under me? Check who controls the copyright. A single company that owns all the code can relicense it whenever they like. A project with distributed contributors and a foundation cannot. The governance tells you the rug-pull risk.
Can I actually leave? If you self-host it and later want out, does your data come with you in a standard format? This is the same exit-plan test I apply to every dependency, license or not.
The traps ranked by how much they hurt
Not all license risk is equal. Prioritize.
Worst: a load-bearing tool under a single-vendor source-available license that could relicense. You depend on it, you cannot fork it cleanly, and the terms can shift. Avoid putting these in your critical path.
Medium: open core where you will predictably need the paid features. This is not a trap so much as a delayed bill. Fine if you price it in and decide the tool is worth it. Bad if you self-hosted specifically to avoid paying and did not read far enough to see the wall coming.
Mild: a permissively licensed tool from a healthy multi-contributor project. This is the real ownership case. You can run it, fork it, and never be forced off it. These are the tools worth building on, the same way I lean on genuinely open foundations for managing secrets and monitoring instead of paid services.
The rule I follow
Before I self-host anything, I check the license the same way I check the exit plan. Permissive and multi-contributor gets a green light. Open core gets a hard look at whether I will hit the paywall. Source-available with a single vendor gets kept off the critical path or skipped.
Self-hosting is supposed to buy you control, and a license can take that control right back without a server ever leaving your possession. Reading the terms is ten minutes that saves you a migration. It is the same instinct as the rest of the own-your-stack approach: know what you are actually agreeing to before you build on it. When you run genuinely open tools on infrastructure you control at HostSSH, no license change and no paywall can reach the thing you are running.