TL;DR De vijf vragen uit m’n licentiepost heb ik eens losgelaten op het OS onder m’n eigen cluster. De licentie houdt stand. De vendor lock-in van Talos Linux zit in twee defaults die naar servers van Sidero wijzen, in de BSL -code die Sidero steeds naast de MPL -kern zet, en in een bedrijf dat sinds 14 september van Yardi is.
M’n licentiepost eindigt met vijf vragen die je aan elk onderdeel van je stack stelt. Aan Talos had ik ze nooit gesteld, en dat is nou net het besturingssysteem waar elke node in m’n homelab van opstart. Negen dagen voordat die post online ging had Yardi Sidero Labs gekocht, het bedrijf dat Talos maakt.
M’n aantekening voor deze post had het antwoord al klaar. Talos is MPL-2.0, dus de licentie is het risico niet. Het risico is de busfactor en een klein ecosysteem, en de oplossing is een eigen buildpipeline en een eigen registry-mirror.
Klopte dat? Deels. Dit is waar het niet klopte.
De licentie gaat nergens heen zonder iedereen
Vraag één is wie het auteursrecht heeft, en of er een CLA is.
Het LICENSE-bestand heeft precies één commit in z’n geschiedenis, de allereerste, op 3 november 2017. Daar stond toen al Mozilla Public License 2.0 in. CONTRIBUTING.md vraagt bij elke commit om een DCO -sign-off, en een CLA zit nergens in de repository. Elke bijdrager houdt z’n eigen auteursrecht. Sidero kan Talos dus niet op eigen houtje herlicentiëren.
Hoe het ook kan, zie je bij Omni, het beheerplatform van Sidero. Sinds januari neemt de contributing-gids bijdragen aan onder 0BSD , en zegt er eerlijk bij waarom. Het gaat om de “flexibility to re-license the project in the future”.
Die voor de hand liggende zorg was dus de verkeerde.
Waar een node standaard mee praat
Als de licentie vastzit, is de volgende vraag wat een draaiende node eigenlijk van Sidero nodig heeft. Volgens m’n aantekening niks. Volgens de docs twee dingen.
Eerst discovery. “By default, Talos uses the service registry”, en de discovery-pagina noemt Sidero’s publieke instance op discovery.talos.dev. De server valt onder BSL 1.1 zonder additional use grant, en zelf hosten gaat “under a commercial license”. Uitzetten kan wel, door de DiscoveryServiceConfig-documenten weg te halen. Dat is gewoon een configwijziging.
Dan de installer. Sinds Talos 1.14, uitgebracht op 3 september, staat in de upgradegids dat “the ghcr.io/siderolabs/installer image is no longer published”. Installers komen van factory.talos.dev. Allebei m’n Talos-posts op deze blog, de introductie en de vergelijking met NixOS, laten een upgradecommando zien dat naar ghcr.io/siderolabs/installer wijst. Voor v1.6 en v1.7, de versies die erin staan, klopte dat.
Kan ik ’m zelf bouwen? Ja, en de builddocs zeggen dat het resultaat “can be pushed to any registry you have access to”. Alleen trekt de standaardbuild kant-en-klare lagen van ghcr.io/siderolabs, en wie elke laag zelf wil bouwen, werkt zich door vijf repositories heen. Eén make is het niet. Een registry-mirror dekt de container-pulls. Voor installer- en boot-images heb je eigen imager-runs nodig of een zelf gehoste Image Factory
, en die is MPL-2.0 op een enterprise/-map na.
Vraag twee gaat over het merk, en die bepaalt hoe een fork mag heten. De README van Sidero’s design system zegt dat forken welkom is en dat de licentie “grants no trademark rights”. Een build die je verder verspreidt, krijgt dus een eigen naam.
Wie betaalt, en wat deden ze eerder
Hier had m’n aantekening gelijk, alleen wel erg kort door de bocht. Het afgelopen jaar schreef één maintainer 47% van de commits aan Talos, de top drie 76%, en minstens 90% kwam van mensen van Sidero.
Vraag drie is wie die mensen betaalt. Sinds kort Yardi. Sidero schrijft dat Talos “remains fully open source under the MPL-2.0 license” en dat het bedrijf zelfstandig blijft draaien. De prijzenpagina verkoopt Talos Enterprise Linux voor $1.000 per node per jaar, minimaal tien nodes, “the same codebase with a commercial layer on top”.
Vraag vijf is of ze dit eerder gedaan hebben. Met Talos niet. Eromheen wel.
| Datum | Wat er gebeurde |
|---|---|
| 2021-10-28 | Discovery service overgezet van MPL naar BSL |
| 2024-02-29 | Omni gepubliceerd, BSL vanaf de eerste commit |
| 2025-12-08 | Image Factory krijgt een BSL-map enterprise/ |
| 2026-05-28 | Change date van go-vex op N/A gezet, dus die wordt nooit open |
| 2026-06-17 | Grant van Omni ingeperkt: alles waar het bedrijf van “depends” telt als productie |
Sidero houdt de kern dus open en zet nieuwe commerciële code er in BSL pal naast. Kwalijk neem ik ze dat niet, iemand moet die 90% betalen. Maar ik weet nu wel waar ik moet kijken als er weer iets verandert.
Waar ik heen zou kunnen, en wat m’n aantekening fout had
Vraag vier is of een uitweg kan beginnen waar ik nu sta. De machineconfig is YAML, en talosctl etcd snapshot levert een gewone etcd-snapshot op. Een node naar m’n eigen build verhuizen zou talosctl upgrade --image met m’n eigen installer moeten zijn, maar getest heb ik dat niet. Helemaal weg van Talos betekent elke node opnieuw installeren, want een in-place pad naar een ander OS is er niet.
Dus heb ik m’n lijstje Talos-eigenschappen ook maar eens naast Flatcar en NixOS gelegd. Twee van m’n eigen Talos-claims hielden geen stand. Talos heeft geen dm-verity
en geen composefs
, en “geen drift” is te sterk, want talosctl edit machineconfig past een draaiende node aan zonder dat Git daar iets van merkt.
| Talos | Flatcar | NixOS | |
|---|---|---|---|
| Read-only OS | squashfs, alleen geverifieerd met Secure Boot | /usr met dm-verity, / schrijfbaar | store ro gemount, niet geverifieerd |
| Atomaire update, rollback | A/B | A/B | generaties |
| Geen shell, geen sshd | ja | sshd standaard aan | shell aanwezig, sshd uit |
| Declaratief | ja, API-edits driften | alleen bij eerste boot | ja, nix-env drift |
| Secure Boot, TPM | allebei, opt-in | alleen TPM | TPM ingebouwd, Secure Boot via Lanzaboote |
| Ephemeral, reset | ja | persistent, flatcar-reset | opt-in, geen resetcommando |
Wat Talos op een Kubernetes-node doet, doet niks anders in die tabel. Daarom draaien m’n nodes erop.
M’n aantekening schatte de uitweg op een registry-mirror. De echte lijst is discovery uit, een imager-build per release of een Image Factory om te draaien, en een eigen naam als ik die build ooit aan iemand anders geef.