Piper installs as piper-tts, and its container image adds Flask for the web server

The install command names a different project than the repository

The README's entire installation instruction is one line:

pip install piper-tts

So does the packaging. The distribution name in the build script is `piper-tts`, and the version there is 1.8.0, which matches the v1.8.0 tag dated 2026-09-04. The repository is called `piper1-gpl`, which is not a package name anyone can install.

Two more identity details sit in the same file. The project URL is written as `http://github.com/OHF-voice/piper1-gpl`, with plain http and with a lower case letter in the organisation name, while every other reference in the README uses `OHF-Voice`. And the description string, fast and local neural text-to-speech engine, is byte for byte the same sentence the repository uses in its own description field.

The one-line description is also the whole architecture statement: the engine is local, and it embeds espeak-ng for phonemization.

The README then presents its capabilities as a row of icon-prefixed links, which between them cover samples, a demo page, a voices document, a command-line interface, a web server, a Python API, a C and C++ API, training new voices, and building manually. Six of those nine are separate documents under `docs/`.

The package metadata still names the Home Assistant authors

The author fields in the build script credit a different organisation than the one running the project.

It declares `author="The Home Assistant Authors"` and an author email at the home-assistant.io domain. The repository, meanwhile, is under the Open Home Foundation, carries that foundation's logo in the README, and has a section titled Looking for Maintainers in which the foundation asks people to send a message to an address at openhomefoundation.org.

So the published package presents itself as Home Assistant work, and the maintenance of the code sits with a foundation. Home Assistant's add-on is the first entry in the README's list of projects using it.

It has a practical consequence for anyone reading package metadata. The author, the contact address and the licence in the index all point at one organisation, and the person asking for help points at another.

The same file also carries a comment that explains an unusual licence entry, noting that g2pW is Apache-2.0 and pointing at a specific source file for the detail.

Flask powers the web API in containers and Python installs

The web server is available outside the container too: the HTTP guide installs `piper-tts[http]`, downloads a voice, and runs `python3 -m piper.http_server -m en_US-lessac-medium`.

The container's runtime stage does this:

ENV PIP_BREAK_SYSTEM_PACKAGES=1
RUN pip3 install ./dist/piper_tts-*linux*.whl
RUN pip3 install 'flask>=3,<4'
EXPOSE 5000

Flask is a separate `pip3 install` line after the wheel, with a version range of 3 up to but not including 4.

Port 5000 is exposed, which is the Flask default rather than a chosen port, and the entrypoint comes from a `docker/entrypoint.sh` script in the repository rather than from anything inside the package.

The environment variable in that first line deserves attention on its own. `PIP_BREAK_SYSTEM_PACKAGES=1` tells pip that it may modify the Python installation shipped in the base image rather than refusing because of an externally-managed environment marker. It is scoped to a container, which is the normal place for it, and it is the sort of setting that gets copied into other Dockerfiles by habit.

The wheel is selected by a glob that matches every Linux build

The runtime stage copies and installs with a shell pattern rather than a resolved filename:

COPY --from=builder /app/dist/piper_tts-*linux*.whl ./dist/
RUN pip3 install ./dist/piper_tts-*linux*.whl

The pattern has two wildcards. Any wheel whose name starts with `piper_tts-`, contains `linux` somewhere, and ends in `.whl` is copied in and handed to pip. A builder that produced wheels for several glibc versions or several architectures would satisfy the pattern more than once, and pip would be given several paths rather than one.

Both stages use Python 3.12, the full image for building and the slim image for running. The build stage installs build-essential, cmake, ninja-build and git, then copies a short list of top-level files, the whole `src/piper/` directory, and three scripts from `script/` named setup, dev_build and package, which it runs in that order.

Those three script names are the entire build system as far as the container is concerned. There is no pip wheel call and no setup.py invocation, so the image assumes a build that produces a wheel under `dist/` already, with a name matching the pattern.

The Python package carries ONNX models, three lexicons and web templates

The build script enumerates the data files it ships, and the list is longer than a text-to-speech package's data usually is.

Two files go in first as a group: `py.typed`, the marker that tells type checkers the package is typed, and `espeakbridge.pyi`, a stub file. The black configuration in the project table excludes exactly one pattern, files ending in `.pyi`, so the generated stub is the only thing the formatter is told to leave alone.

Then come four language-specific directories, each enumerated with a hardcoded file list. A `tashkeel` directory holds `model.onnx` and three JSON id maps for input, target and hints. A `hebrew` directory holds `nakdimon.onnx` plus its own LICENSE and SOURCE files. A `lithuanian` directory holds three tab-separated lexicons plus its own LICENSE and SOURCE files. An `espeak-ng-data` directory is walked recursively rather than enumerated, with every file inside it included.

The presence of LICENSE and SOURCE files inside two of those directories is the detail that matters for anyone redistributing. Each bundled dataset carries its own terms, and they live inside the installable package rather than in a repository-level notices file.

The HTTP server's own assets are collected the same way, from `templates/` and `img/` directories inside the package, under a comment naming them as the web page and images for the server. So the user interface ships inside the wheel.

A GPL-3.0-or-later package declares two licence files

The licence is GPL-3.0-or-later, and the licence file list has two entries: `COPYING` and a file under a `licenses/` directory whose name carries the component and its licence, `LICENSE.g2pW-Apache-2.0`.

The comment above that line names the reason. g2pW is Apache-2.0, and a source file is pointed at for the detail. So a GPL package carries an Apache-2.0 component, which is compatible in that direction, and the build is explicit about it by shipping the Apache text rather than relying on the GPL notice to cover it.

The build system is a similar mixture, and it is worth knowing which half does what. The project table declares five build requirements, scikit-build, setuptools, wheel, cmake and ninja, and names `setuptools.build_meta` as the build backend. The build script itself does not call setuptools directly; it imports `setup` from `skbuild`, which is scikit-build, and its only stated purpose is so package data is included. So scikit-build drives the CMake step for the C and C++ side while setuptools remains the declared entry point.

There is a separate `libpiper/` directory at the root for the C and C++ API, and the primary language recorded for this repository is C++.

The foundation running the project is advertising for maintainers

There is a section in the README headed Looking for Maintainers, and it is one sentence. The Open Home Foundation is looking for maintainers for Piper, and anyone interested is asked to send a message to an address at the foundation's domain.

That statement sits between the feature links and the list of projects using Piper, so it is placed where a reader cannot miss it and where it is not framed as a risk. It is the plainest maintenance signal the project publishes.

The commit history does not read abandoned. The most recent push is dated 2026-10-30, the last three releases are v1.6.1 on 2026-08-13, v1.7.0 on 2026-08-15 and v1.8.0 on 2026-09-04, and the repository carries a changelog, a Dockerfile, a test directory, a tox configuration and separate mypy, pylint and isort settings.

So the honest reading is a project with recent releases and an open request for staffing, not a project that has stopped. What that means for an adopter is a question about who answers an issue, not about whether the code still moves.

The last entry in the README's list of users is a plain-language text-to-speech converter site, which is a different kind of reference from the screen reader and the game client listed above it.

Editorial conclusion

Piper fits a project that needs speech generated on the machine it runs on rather than sent to a service, with phonemization handled by an embedded espeak-ng and models shipped in the wheel. Four things to know before you install it. The distribution is named `piper-tts`, not `piper1-gpl`, so the repository name will not resolve. The Python metadata still carries the Home Assistant authors and contact address even though the project is run by the Open Home Foundation, which is also actively advertising for maintainers at an address in its own README. The HTTP server needs Flask, which the container image installs as a separate step after the wheel. And a GPL-3.0-or-later package with an Apache-2.0 component inside it ships both licence texts, so check `licenses/` if you redistribute.

Frequently asked questions

Official sources

1. Issues
2. License: GPL-3.0
3. OHF-Voice/piper1-gpl on GitHub
4. README
5. Releases