The pitch for replacing a paid SaaS with an open-source equivalent is almost always framed as a cost story. You stop paying per seat, you run the thing yourself, you keep the savings. What that framing quietly skips is that “open source” is not one legal regime. It is at least three, and the difference between them decides whether self-hosting is a free lunch or a disclosure obligation you didn’t sign up for.
For this directory I end up reading a lot of license files, and the mistake I see most often is treating the license as a formality — a checkbox after the feature comparison. It belongs at the front of the decision, because the license, not the feature list, is what changes when your usage changes.
Three buckets that actually matter
Start with the permissive family: MIT, Apache 2.0, BSD. These let you use, modify, host, embed, and even resell the software with very little friction. The main duties are keeping the copyright notice and, in Apache’s case, noting your changes and respecting its patent grant. For a company that wants to self-host an internal tool — or build a product on top of one — this is the safe ground. If the alternative you’re eyeing is MIT or Apache 2.0, the license is rarely the thing that will hurt you.
The copyleft family is where intent matters. Weak copyleft — LGPL, MPL 2.0 — is scoped to the licensed files or library. You can link your proprietary code against an LGPL library and keep your own code closed, provided you let users relink against a modified version of the library; MPL 2.0 keeps obligations at the per-file level. Strong copyleft — GPL — pulls your derivative work into the same license when you distribute it.
The detail that trips up SaaS-replacement projects is the word “distribute.” Classic GPL was written for shipped software, and running a modified program on your own server to offer a service has historically not counted as distribution. AGPL closes exactly that gap: if you let users interact with a modified version over a network, you must offer them the corresponding source. That is the clause that turns “host it yourself” from a non-event into a publishing commitment the moment you fork and modify.
Then there is the bucket that isn’t open source at all in the OSI sense, even though it lives on GitHub and reads like it: source-available. Business Source License (BUSL/BSL), the Elastic License, the Server Side Public License (SSPL). You can read the code, often run it, frequently use it internally for free — but a clause restricts the one thing a competitor would want to do: offer it as a managed/hosted service, or otherwise compete with the vendor. The source is visible; the commercial freedom is fenced.
Why the recent relicensing wave is the real lesson
These aren’t abstractions. The market has spent the last several years rearranging itself around exactly this boundary:
- MongoDB moved from AGPL to its own SSPL in 2018. SSPL’s headline clause says that if you offer the software as a service, you must release the source of the entire service stack used to provide it — a condition designed to be impractical for a hosting competitor. The Open Source Initiative declined to treat SSPL as an open-source license (OSI: “The SSPL is Not an Open Source License”).
- Elastic changed Elasticsearch and Kibana away from Apache 2.0 in 2021, to a dual SSPL / Elastic License arrangement, in an open dispute with AWS over hosted Elasticsearch. (Elastic later added the AGPL as an option in 2024, which is a different posture again — AGPL is OSI-approved copyleft, not source-available.)
- HashiCorp relicensed Terraform and its other core tools to the BUSL in 2023 (HashiCorp’s license-change announcement). The community response was the OpenTofu fork, which continues from the last open (MPL 2.0) Terraform code.
- Redis shifted away from its BSD license in 2024 toward a source-available model, which triggered the Valkey fork backed by other vendors; Redis then added AGPLv3 as an additional license option in Redis 8 (2025).
Read together, these tell you something the per-tool feature page won’t: a license is a moving target. A project that is Apache today can become source-available tomorrow, and the version you adopt is the version you’re entitled to — but upgrades may come under new terms. That is a planning input, not a surprise.
The question that decides your exposure
For almost every tool, the practical risk hinges on one fork in the road:
Self-host for internal use. You run the software, unmodified or lightly modified, behind your own walls to serve your own employees. Under permissive and ordinary copyleft licenses, this is broadly fine. Even most source-available licenses carve out internal use — BUSL and the Elastic License generally let you self-host for your own operations. AGPL’s network clause technically applies, but if you haven’t modified the code and aren’t exposing it to outside users, the corresponding-source duty is light. This is the low-risk lane, and it’s where most “replace our SaaS” projects actually live.
Modify and offer it as a hosted product. Now every line above flips. AGPL means your modifications must be offered as source to your users. SSPL aims that obligation at your whole service stack. BUSL and the Elastic License may simply prohibit the managed-service use case outright until the change-date or a commercial agreement. If your plan is to wrap an open-source engine and sell access to it, the license is no longer a detail — it is the business model’s gatekeeper.
So before you migrate, do three boring things: read the actual LICENSE file in the repo (and confirm the SPDX identifier rather than trusting a marketing page), decide honestly which of the two lanes you’re in, and check whether a community fork exists for tools with a relicensing history — forks like OpenTofu and Valkey are often the genuinely-open continuation. None of this is legal advice; for a revenue-bearing decision, have counsel read the same clauses you did. But the engineering judgment — internal tool versus hosted product — is yours to make, and it’s the variable that matters most.