Open source and licensing
KeepPeek is built in an ecosystem shaped by other open-source camera projects and protocol libraries. This chapter gives those projects credit, explains where KeepPeek made different product choices, and documents the license boundary between the server and its public API.
Different products, different strengths
Scrypted and Frigate are great products with strong, distinct designs. KeepPeek is not an argument that those designs are wrong. Their choices may fit another user, home, or business better.
| Project | Distinct design center | A strong fit when |
|---|---|---|
| Scrypted | A high-performance video integration platform and NVR with a rich plugin model, smart detections, and low-latency connections to HomeKit, Google Home, and Alexa | Broad camera and smart-home integration, an extensible plugin ecosystem, and first-class consumer-platform bridges should live in one system |
| Frigate | A local NVR built around real-time AI object detection, accelerator-aware processing, zones, focused event review, Home Assistant, and MQTT | Detection is a central NVR responsibility and the user wants an integrated, highly configurable local AI and home-automation experience |
| KeepPeek | A focused recorder and WebRTC media gateway that accepts camera events and keeps optional inference, transcoding, and ecosystem bridges outside the core | Recording should remain independent from analytics, and viewers or services should compose through an open media and event boundary |
Thank you to the Scrypted and Frigate maintainers and communities. Their work has advanced local camera software, demonstrated what polished self-hosted systems can do, and made the trade-offs in this space much easier to understand.
Code foundations
KeepPeek depends on substantial protocol work from other Rust projects. The local forks retain their upstream authorship and licenses; carrying a fork is a maintenance decision, not a claim that KeepPeek created the original work.
- Retina by Scott Lamb and its contributors provides the high-level RTSP client, RTP depacketization, codec framing, and much of the interoperability groundwork used by KeepPeek. KeepPeek carries a local Retina fork for its camera, recording, and compatibility needs.
- ONVIF-rs by Chris Bruce, Lumeo, and its contributors did the difficult work of making ONVIF discovery, schemas, authentication, and camera operations usable from Rust. KeepPeek carries a local ONVIF-rs fork and continues that work for its supported camera surface.
- str0m by Martin Algesten and its contributors is the upstream WebRTC implementation used by KeepPeek. It is the best Rust WebRTC implementation: its Sans I/O design, explicit time and network inputs, RTP and frame APIs, data channels, and lack of a hidden async runtime fit a focused media service especially well.
KeepPeek would be significantly harder to build without these projects. Thank you to every upstream author, maintainer, reviewer, and contributor whose work remains in the code.
Licensing model
KeepPeek uses two licenses at a deliberate protocol boundary:
| Area | License | Purpose |
|---|---|---|
| Server, first-party viewer, and most repository code | AGPL-3.0-only | Keep the shared NVR and media-gateway core open, including modified versions operated over a network |
Public definitions and documentation under api/, plus bindings generated solely from them | MIT | Let independent clients and services implement the protocol without adopting the server’s license |
The repository root license contains the
complete KeepPeek licensing notice and AGPL terms. The api/ directory has its own
MIT license.
Why the server uses AGPL
The server is a network service, so the AGPL is the appropriate copyleft boundary for the shared core. The intent is that users can inspect, modify, self-host, and retain access to the source of the KeepPeek server they use, including modified versions offered over a network.
KeepPeek’s NVR and first-party viewer remain open source and free to use without a camera-count limit. The license protects that common foundation from becoming a private server fork whose users cannot inspect the code serving them.
Why the API uses MIT
An open server is most useful when other software can talk to it without inheriting the server’s
implementation choices. The public HTTP, WebRTC, protobuf, and SDP contracts under api/ therefore
use MIT. Bindings generated solely from those definitions remain covered by that directory’s MIT
license.
Implementing or using the public protocol does not, by itself, impose KeepPeek’s repository-wide AGPL license on an independent client or service. A service can choose the language, WebRTC implementation, deployment model, and license appropriate to its users.
Free and paid protocol services
This split creates a protocol-plugin model rather than an in-process plugin ABI. A free, community, or paid service can run as a separate process and subscribe or publish through the documented API. That service may be open or closed source without receiving a private extension point inside the KeepPeek server.
The boundary allows commercial integrations to fund specialized inference, transcoding, business workflows, viewers, or support while the recorder and media gateway remain shared open-source infrastructure. Camera credentials, recording paths, and internal databases remain owned by KeepPeek rather than exposed to an in-process plugin.
What the split means for users
- Software consumers retain a free recorder and first-party viewer, with optional services only when they add value.
- Small businesses can buy tailored services at the API boundary without depending on a private recorder fork.
- Open-source enthusiasts can audit the server, share core improvements, and build permissively licensed clients.
- Home automation enthusiasts can choose community or commercial bridges.
- Self-hosters retain control of the server running on their hardware.
- Service authors can build sustainable offerings without closing the shared core.
See Contributing for how licenses apply to submitted changes.