Third-Party Components

SpatiumDDI is an assembly job as much as it is a codebase. It does not reimplement DNS or DHCP — it runs BIND9, PowerDNS, Technitium and Kea, and it runs them on a Kubernetes distribution it did not write, on an operating system it did not write. This page is the catalogue of everything in that stack: what it is, which artifact it ships in, what license it carries, and why it is there.

Two files cover this ground, and they are not the same thing.

If the two ever disagree about a license, NOTICE wins and the discrepancy is a bug worth filing.

Neither file enumerates every transitive dependency. They cover components that are bundled, shipped, or directly depended on — the things an operator can point at in a running system, and the things a license auditor asks about. The full transitive set for the Python and npm layers lives in backend/pyproject.toml + frontend/package-lock.json; for the OS layer, ask the package manager on a running appliance (see Verifying a running system).

Artifacts

The “Where” column throughout this page refers to these:

Versions below are the pins on main at the time of writing. They move; the Pinned in column names the file that is actually authoritative, and that is the one to check rather than trusting this table’s numbers.

DNS, DHCP and routing engines

The reason the project exists. Every one of these is a separate upstream daemon running as its own process — SpatiumDDI generates their configuration and talks to their control channels, it does not link against them.

Notes worth carrying:

• Technitium runs on .NET. Its image is Ubuntu-based (upstream’s own base), not Alpine like the other agents, and it pulls in the ASP.NET Core runtime. It is the one DNS engine whose base image SpatiumDDI does not choose.
• dnsdist is not a general DNS server here. It exists to give PowerDNS inbound DoT/DoH, which pdns-auth does not speak natively. See DNS.
• Kea 3.0 imposes path restrictions on hook libraries and socket paths as a result of CVE-2025-32801/2/3. The Dockerfile carries a prominent warning about this; the paths in it are load-bearing, not stylistic.

Kubernetes and orchestration

Three of these deserve a sentence, because their state is not what you would assume from their presence:

• Traefik and metrics-server ship but are disabled. They arrive inside the k3s airgap image tarball, which is a single artifact — you cannot fetch a k3s release without them. The appliance disables both in config.yaml: operator TLS goes through the existing nginx reverse proxy, and metrics-server costs ~80 MiB RSS for something not yet surfaced.
• MetalLB is pinned to 0.15.3 deliberately, chart and images together. 0.16.0 regressed the speaker into an apiserver-flooding reconcile loop (metallb#3063), and pinning only the images while keeping the newer chart crashloops on a health probe the older binary does not serve.
• FRRouting is GPL v2 and only enters the picture when an operator opts into BGP-mode MetalLB. Both bgp.enabled and frrk8s.enabled default to false.

Data services

On Redis’s license: Redis relicensed away from BSD at 7.4 (RSALv2 + SSPLv1) and added an AGPLv3 option at 8.0. SpatiumDDI ships the stock upstream redis:8.8-alpine image unmodified and talks to it as a network service over its own protocol — no Redis code is linked into or vendored by SpatiumDDI.

Operators who would rather not run that license family can point the deployment at any Redis-protocol-compatible server via the connection URL. The control plane uses only GET / SET / DEL / INCR / EXPIRE / SCAN and pub/sub — no modules, no Lua, no streams — and Celery’s Redis broker is the other consumer. This is an untested configuration rather than a supported one; if you run SpatiumDDI on a Redis alternative, tell us how it went.

The Helm chart used to bundle Bitnami’s PostgreSQL and Redis subcharts. Bitnami pruned its Docker Hub namespace in late 2025 in favour of paid images, so the pinned tags stopped resolving; the chart now ships plain StatefulSets using the official upstream images instead.

Control-plane backend (Python)

Runs in the API image. Authoritative list, with versions: backend/pyproject.toml.

Cloudflare has no SDK entry on purpose. The Cloudflare DNS driver speaks plain REST over httpx rather than pulling in the official SDK, which ships a pydantic-v1 compatibility shim.

On the two copyleft Python libraries: ldap3 (LGPL v3) and paramiko (LGPL 2.1) are imported as libraries into an Apache-2.0 application. LGPL permits this; what it requires is that a recipient can replace the library. They are installed as ordinary, separately-replaceable site-packages in the image — nothing is statically linked or vendored.

Agent runtimes (Python)

The DNS, DHCP, Looking Glass and supervisor agents each carry a much smaller dependency set than the control plane. Common to all: httpx, structlog, pydantic.

Frontend

Runs in the frontend image. Authoritative list: frontend/package.json.

Appliance operating system

The bootable image is Debian 13 (trixie), built with mkosi. The full package list is appliance/mkosi.conf — this is the operator-meaningful subset.

There is no Docker on the appliance. It was removed in #183 Phase 7 — the image is k3s-only, and k3s’s static binary carries its own containerd plus kubectl / ctr / crictl as argv symlinks.

Operator tooling inside the API image

The Tools page (/tools) and PCAP capture shell out to real binaries, so they ship in the API image rather than being reimplemented. All are invoked through a sandboxed argv builder, never a shell string.

nmap’s license is not OSI-approved. The NPSL is a GPL v2 derivative with added restrictions on redistribution inside commercial products. SpatiumDDI is Apache 2.0 and ships nmap as an unmodified, separately-installed Debian package invoked as a subprocess — no linking, no derivative work. Anyone repackaging SpatiumDDI commercially should read the NPSL themselves rather than assume the Apache license covers it.

Container bases and init

Alpine is pinned at 3.23, not 3.24, and that pin is load-bearing: 3.24 ships Python 3.13 while the agent Dockerfiles install into 3.12 paths, which produces a ModuleNotFoundError crashloop rather than a build failure. Dependabot is configured to hold the pin.

Build and test toolchain

Not shipped to operators — listed because a contributor will meet all of it, and because CI gates depend on specific behaviour from several.

License obligations

SpatiumDDI itself is Apache 2.0. Everything above keeps its own license. The combination is distributed as separate, independently-installed programs — container images built from upstream distribution packages, and a disk image built by a distribution’s own package manager. Nothing copyleft is statically linked into, or vendored inside, the Apache-2.0 codebase.

The practical consequences:

• GPL components ship unmodified. BIND9, PowerDNS, dnsdist, Technitium, Scapy, FRRouting, HAProxy and the Debian host userland are all upstream binaries installed from their distributions’ repositories. Source for each is available from the distribution that packaged it, on the terms in that package’s license.
• The two LGPL Python libraries (ldap3, paramiko) are imported, not linked or vendored, and are replaceable in place inside the image.
• nmap’s NPSL is the one license here that is not OSI-approved and carries redistribution conditions Apache 2.0 does not. See the note above.
• Technitium is GPL v3 and, unlike the other engines, runs from upstream’s own container image with a digest pin. SpatiumDDI adds the sync agent as a separate process in that image; it does not patch the server.

If you are performing a license review and need something this page does not answer, open an issue — that is a documentation bug, not a support question.

Verifying a running system

This page can drift. A running system cannot.

Python packages in the API image, with versions and licenses:

docker compose exec api python3 -m pip list
docker compose exec api python3 -m pip show ldap3 paramiko

OS packages on the appliance:

dpkg-query -W -f='${Package}\t${Version}\t${Homepage}\n' | sort

Packages inside an Alpine-based agent image:

docker compose exec dns-bind9 apk list --installed

What k3s actually bundles in the release you are running — the manifest is baked onto the appliance at build time, alongside k3s’s own LICENSE:

cat /usr/share/doc/k3s/k3s-images.txt
cat /usr/share/doc/k3s/LICENSE

Images running on the appliance’s k3s cluster right now:

kubectl get pods -A -o jsonpath='{range .items[*].spec.containers[*]}{.image}{"\n"}{end}' | sort -u

See also

• NOTICE — the shipped attribution notice
• Architecture — how these components fit together
• DNS Drivers / DHCP Drivers — how SpatiumDDI drives the engines
• OS Appliance — how the image is built
• Kubernetes — the umbrella chart