No mainstream software licence stops you from self-hosting at home. AGPL, BSL, SSPL, and every source-available variant all permit personal use without conditions you'll ever trigger. What a licence actually tells you is how the project expects to make money — and therefore how it's likely to behave when funding gets tight. Read licences as forecasts about the project's future, not as rules for your basement.
The short table
| Licence | Homelab use | Build a product on it | What it signals |
|---|---|---|---|
| MIT / Apache-2.0 | Yes | Yes, anything | Adoption first; sustainability is tomorrow's problem |
| GPLv3 | Yes | Yes; share changes you distribute | Classic copyleft, well understood |
| AGPLv3 | Yes | Yes; share changes you serve over a network | Keeps cloud vendors honest |
| BSL 1.1 | Yes | Read the Additional Use Grant; no competing service | VC-funded; opens up after ≤4 years |
| SSPL | Yes | Not as a managed service | Aimed squarely at AWS; not OSI-approved |
| ELv2 / FSL / fair-code | Yes | Usually, except reselling it as a service | "Open enough" — the clause is the contract |
The pattern: every restriction in the bottom half targets one entity — a hyperscaler offering the software as a competing managed service. A homelab is invisible to all of them.
AGPL is a filter, not a trap
The AGPL's network clause triggers when you modify the software and let others use it over a network — then you must offer them your modified source. Running stock Nextcloud for your family triggers nothing. Running a patched fork as a public SaaS triggers everything, which is the point. This is why so much of self-hosting is AGPL — Nextcloud, Grafana (since 2021), Immich — and why the licence's scary reputation among corporate lawyers works in the community's favour: it makes "deploy it internally, contribute fixes upstream" the path of least resistance.
BSL: source-available with a built-in expiry
The Business Source License is a timed compromise: source is public, a use restriction (typically "no competing managed service") applies, and on a change date at most four years out, each version converts to a genuinely open licence, usually Apache 2.0. You can read the template at mariadb.com/bsl11. For a self-hoster, BSL software runs exactly like open source. The real risk is ecosystem schism, as HashiCorp demonstrated in 2023: Terraform's move to BSL produced the OpenTofu fork under the Linux Foundation within weeks, and the community's centre of gravity moved with it.
The relicensing waves, and what the forks did
The 2021–2025 record is consistent enough to treat as a playbook:
- Elastic went SSPL (2021); AWS forked OpenSearch; Elastic added AGPL back as an option in 2024.
- HashiCorp went BSL (2023); OpenTofu forked under the Linux Foundation.
- Redis went SSPL/RSAL (2024); Valkey forked under the Linux Foundation and became the default swap; Redis added an AGPL option in 2025.
- Gitea's move under a company (2022) raised governance concerns; Forgejo hard-forked from Gitea and later relicensed to GPLv3+, and is now what most self-hosters deploy.
Two lessons. First, forks are credible now — foundations adopt them in weeks and distros follow. Second, your migration cost as a self-hoster is usually one line: image: redis:7 becomes image: valkey/valkey:8. Relicensing stopped being an existential event for homelabs around 2023; it's a container rename with extra drama.
What predicts a relicense
You can score a project's relicensing risk in ten minutes:
- A CLA that assigns rights to a single company means they can relicense unilaterally. DCO-only projects with hundreds of copyright holders effectively can't — every Linux-style contributor would need to agree.
- Single-vendor copyright plus VC funding plus a hyperscaler offering a hosted version is the exact profile of every conversion above.
- Watch the open-core boundary: features migrating from the open edition to the paid tier is the leading indicator, visible in changelogs a year before any licence change.
# Quick checks: licence, and whether a CLA gates contributions
gh api repos/immich-app/immich --jq .license.spdx_id
gh api repos/immich-app/immich/contents/CONTRIBUTING.md \
--jq .content | base64 -d | grep -i -c "CLA"What this means for your startup, in one paragraph
Using any of these licences internally, or self-hosting them as infrastructure for your business, is fine across the board — including SSPL and BSL. The lines you can't cross: building a product that is the software offered as a service (BSL/SSPL/ELv2 territory), and modifying AGPL software you expose to customers without publishing the changes. If your product merely talks to the software — your app uses a BSL database, your CI runs on AGPL Forgejo — you're clear. When in doubt, the specific Additional Use Grant is short; read it before the lawyer does.
Bottom line
For the homelab, ignore the licence and weigh project health instead — bus factor, release cadence, and who's actually funding it predict your five-year experience far better than the SPDX identifier does. Keep compose files in git so the inevitable fork-swap is a one-line diff. And treat a new CLA requirement or a feature quietly moving to the paid tier as your twelve months' notice.