The Capy CLI is licensed under AGPL-3.0. The service backend is closed-source. This page exists because AGPL has a reputation for being scary, and most of that reputation does not apply to how teams actually use Capy.Documentation Index
Fetch the complete documentation index at: https://capy.sc/docs/llms.txt
Use this file to discover all available pages before exploring further.
The 30-second answer
If you are installingcapy and using it as a CLI on developer machines, in CI, and in deploy pipelines — AGPL imposes no obligations on you. You are not modifying it, you are not distributing it, you are not exposing it as a service. You are a user. AGPL has nothing to say about users running unmodified software.
If any of the following are true, read the rest of this page:
- You forked Capy and changed the source.
- You bundled Capy into something you ship to other people.
- You exposed Capy’s functionality over a network to users (e.g., a web UI on top).
Decision tree
”I’m just installing the CLI and using it.”
No obligations. Carry on.”I forked Capy to fix a bug or add a feature, and we use it internally.”
No obligations — provided the fork stays inside your organization and is not made available to outside users (including over a network). AGPL is triggered by distribution and network use by third parties, not by internal modification.”I forked Capy and we publish the binary internally to our team.”
Probably no obligations — internal use within the same legal entity is generally not “distribution.” If you distribute to contractors, partners, or other entities, see the next entry.”I forked Capy and we distribute the binary or source to people outside our company.”
You must offer the source of your modifications under AGPL-3.0 to the people you distribute to. This is standard copyleft. Your modifications inherit the license; the rest of your codebase does not (unless it links the modified Capy code as a library, which Capy is not designed for — it is a CLI).”I forked Capy and built a hosted SaaS on top of it that users interact with over a network.”
AGPL §13 applies. You must offer the source of your modified version to users who interact with it over the network. This is the “AGPL clause” — the thing that distinguishes AGPL from GPL. If you are doing this, you should already know.”I want to embed Capy as a library inside my proprietary application.”
Don’t. Capy is intentionally not designed as an embeddable library. The CLI is the unit of distribution. Linking AGPL code into proprietary code is the case AGPL is designed to prevent. If you want programmatic access to a Capy project’s secrets from within an application, the supported pattern is to invokecapy run -- your-app so secrets land in process.env. Your app stays vanilla.
The specific scenarios that come up
“Our CI runscapy run to inject secrets into tests.”
Fine. You are a user. No obligations.
“We baked Capy into a Docker image we publish on Docker Hub.”
You are distributing the unmodified Capy binary. The AGPL allows this and requires you to include a copy of the license and a way for recipients to obtain the source. In practice this means: ship the LICENSE file inside the image and link to github.com/capysc/capy-cli in your README. No source disclosure of your code is required.
“We patched Capy to add a custom auth provider, and we publish the patched binary to our customers.”
You must offer the source of your patched Capy to those customers. Your customers’ applications are unaffected.
“We’re a security vendor and we want to white-label Capy.”
Talk to us — hello@capy.sc. There is a path that does not require AGPL release of your wrapper, but it is a license conversation, not a code conversation.
Why AGPL and not MIT
This question comes up. The honest answer:- The cryptography and the CLI are the trust surface. AGPL keeps the trust surface auditable in perpetuity. A MIT-licensed CLI could be quietly forked and closed-sourced by a buyer, which would erode the zero-trust claim Capy is built on.
- AGPL imposes zero cost on the 99% case (using the unmodified CLI). It only kicks in when someone tries to ship a modified version as a closed product, which is the case the license is designed to prevent.
- The service is closed-source for separate reasons (it is the managed product). The CLI is the part users run, the part users care about, and the part that needs to stay open.