TL;DR I ran the five questions from my licence post on the OS under my own cluster. The licence holds. The Talos Linux vendor lock-in sits in two defaults that point at Sidero’s servers, the BSL code Sidero keeps adding around the MPL core, and a company Yardi has owned since 14 September.
My licence post ends with five questions to ask of every component you run. I didn’t ask them of Talos, which is the operating system every node in my homelab boots. Nine days before that post went out, Yardi had bought Sidero Labs, the company that makes it.
My note for this post already had an answer. Talos is MPL-2.0, so the licence isn’t the risk. The risk is bus factor and a small ecosystem, and the fix is an own build pipeline and an own registry mirror.
Was the note right? Partly. Here’s where it wasn’t.
The licence can’t move without everyone
Question one is who owns the copyright, and whether there’s a CLA .
The LICENSE file has exactly one commit in its history, the initial one on 3 November 2017, and it said Mozilla Public License 2.0 then. CONTRIBUTING.md asks for a DCO sign-off on every commit and there’s no CLA anywhere in the repository. Every contributor keeps their copyright, so Sidero can’t relicense Talos on its own.
Omni, Sidero’s management platform, shows what the other setup looks like. Since January its contributing guide takes contributions under 0BSD , and says why, the “flexibility to re-license the project in the future”.
So the obvious worry was the wrong one.
What a node talks to out of the box
If the licence can’t move, the next question is what a running node needs from Sidero. My note said nothing. The docs say two things.
Discovery first. “By default, Talos uses the service registry”, and the discovery page names Sidero’s public instance at discovery.talos.dev. The server is under BSL 1.1 with no additional use grant, and self-hosting it takes “a commercial license”. You can switch it off by removing the DiscoveryServiceConfig documents, so that one’s a config change.
Then the installer. Since Talos 1.14, released 3 September, “the ghcr.io/siderolabs/installer image is no longer published”, according to the upgrade guide. Installers come from factory.talos.dev. Both of my Talos posts on this blog, the introduction and the NixOS comparison, show an upgrade command pointing at ghcr.io/siderolabs/installer. They were right for v1.6 and v1.7, the versions they show.
Could I build my own? Yes, and the build docs say the result “can be pushed to any registry you have access to”. But the default build pulls prebuilt layers from ghcr.io/siderolabs, and rebuilding every layer means working through five repositories, not one make. A registry mirror covers container pulls. Installer and boot images need your own imager runs or a self-hosted Image Factory
, which is MPL-2.0 apart from an enterprise/ directory.
Question two is the trademark, and it settles what a fork may call itself. Sidero’s design system README says forking is welcome and that the licence “grants no trademark rights”. A redistributed build needs its own name.
Who pays, and what they did before
Here the note was right, and short. Over the last twelve months one maintainer wrote 47% of the commits to Talos, the top three wrote 76%, and at least 90% came from Sidero people.
Question three is who pays them. Yardi does now. Sidero says Talos “remains fully open source under the MPL-2.0 license” and that it runs as a standalone company. The pricing page sells Talos Enterprise Linux at $1,000 per node per year, ten nodes minimum, “the same codebase with a commercial layer on top”.
Question five is whether they’ve done it before. Not to Talos. Around it, yes.
| Date | What happened |
|---|---|
| 2021-10-28 | Discovery service relicensed from MPL to BSL |
| 2024-02-29 | Omni published under BSL from the first commit |
| 2025-12-08 | Image Factory gets its BSL enterprise/ directory |
| 2026-05-28 | go-vex’s change date set to N/A, so it never converts |
| 2026-06-17 | Omni’s grant narrowed to count anything the business “depends” on as production |
So Sidero keeps the core open and puts the new commercial code in BSL right next to it. I don’t hold that against them, somebody has to pay for that 90%. It does tell me where to look when the next change comes.
Where I’d go, and what my note got wrong
Question four is whether an exit can start from where I am. The machine config is YAML, and talosctl etcd snapshot gives a plain etcd snapshot. Moving a node onto my own build should be talosctl upgrade --image with my installer, but I haven’t tested that. Leaving Talos entirely means reinstalling each node, because there’s no in-place path to another OS.
So I checked my note’s list of Talos properties against Flatcar and NixOS as well. Two of my Talos claims didn’t survive. There’s no dm-verity
and no composefs
in Talos, and “no drift” is too strong, because talosctl edit machineconfig changes a live node without touching Git.
| Talos | Flatcar | NixOS | |
|---|---|---|---|
| Read-only OS | squashfs, verified only with Secure Boot | /usr with dm-verity, / writable | store mounted ro, not verified |
| Atomic update, rollback | A/B | A/B | generations |
| No shell, no sshd | yes | sshd on by default | shell present, sshd off |
| Declarative | yes, API edits drift | first boot only | yes, nix-env drifts |
| Secure Boot, TPM | both, opt-in | TPM only | TPM in-tree, Secure Boot via Lanzaboote |
| Ephemeral, reset | yes | persistent, flatcar-reset | opt-in, no reset command |
Nothing else on that table does what Talos does on a Kubernetes node, which is why my nodes run it.
My note priced the exit at a registry mirror. The real list is discovery switched off, an imager build per release or an Image Factory to run, and a new name if I ever hand the build to someone else.