**Piper** is the neural text-to-speech engine that quietly ended up inside a large share of the self-hosted voice stack — **Home Assistant**, the **NVDA** screen reader, **LocalAI**, **Open Voice OS** and a long tail of hobby projects all speak through it — and `piper1-gpl` is its current home under the **Open Home Foundation**. The pitch has not changed since the Rhasspy days: synthesis runs entirely on the local machine, fast enough for a Raspberry Pi, with no API key and no audio leaving the device. The repository sits at **5,193 stars and 500 forks**, is written mostly in **C++**, and ships as `pip install piper-tts`. The architecture is deliberately unfashionable. Voices are trained with **VITS** and exported to **ONNX Runtime**, so a voice is just two files — an `.onnx` model and an `.onnx.json` config — that you drop next to the binary. Text is turned into phonemes by an embedded **espeak-ng**, which is where both the breadth and the license come from: espeak-ng's own GPL terms are why this repository is **GPL-3.0** rather than the permissive license the older Piper carried. That single dependency is what lets a small model cover the ground it does — **44 language/locale entries** in the voice catalogue, from `en_US` and `de_DE` through Georgian, Kazakh, Malayalam, Swahili and Nepali. Release **v1.7.0**, published **15 August 2026**, is the most interesting change in a while because it breaks the espeak monopoly on phonemization. Japanese now has a dedicated phonemizer built on **OpenJTalk** (`pyopenjtalk-plus`) behind a new `ja` extra, added precisely because espeak-ng has no kanji coverage — it reads out Unicode character names — and no pitch accent at all. Full-context labels are parsed for pitch accent and mapped onto IPA, which keeps Japanese voices compatible with the existing IPA-based warmstart rather than forking the training path. The same release added `piper_create_options` and `piper_create_with_options()` to **libpiper**, with the old `piper_create()` retained as a wrapper for ABI compatibility. Surface area is broad for a project this size: a command-line interface, an HTTP web server, a **Python API**, a **C/C++ API** via libpiper, a documented path for **training new voices**, and community bindings such as Piper JNI for Java. That combination is why it shows up as the TTS backend in other people's products rather than as a product itself. Two caveats belong on the record. First, the Open Home Foundation has an open call in the README stating it **is looking for maintainers** for Piper — a governance signal worth weighing before building a product on it. Second, licensing is not uniform: the project describes itself as intended for personal use and text-to-speech research, and each voice ships its own `MODEL_CARD`, some of which carry restrictive terms. The engine being GPL-3.0 tells you nothing about whether a specific voice is cleared for commercial use; that has to be checked per voice.