Secrets tool licenses, demystifiedWhat you can deploy, share, and audit.

Every secrets management tool ships with a license. That license is not a formality. It controls whether you can run the tool on-premises, inspect the code that handles your credentials, fork and modify it if the vendor pivots, or offer it as a service to your own customers.

Procurement teams sometimes treat licensing as a legal checkbox. Engineers sometimes treat it as someone else's problem. Neither posture works when you are picking the system that guards your production database passwords, API keys, and signing certificates.

The 2023 HashiCorp BSL switch caught teams mid-deployment. The Infisical AGPL terms created friction for companies that wanted to embed it inside a commercial product. Neither situation was ambiguous in the license text; both were surprises to teams that had not read the text.

Below is a walkthrough of the major license families you will encounter in the secrets tooling space, what each permits, and the questions worth asking before you commit.

What to know in 60 seconds

• Apache 2.0, MIT, and BSD let you do almost anything. Self-host, fork, embed in a product, no conditions except attribution.
• MPL 2.0 has file-level copyleft. If you modify an MPL-licensed file, you share that file back. You do not have to open-source the rest of your product.
• BSL (Business Source License) is source-available, not open source. It restricts production use to non-competing deployments until a conversion date, then converts to Apache 2.0 or another open license.
• FCL (Functional Source License) is similar to BSL but narrower. It restricts competitors specifically, not all production use. Converts to Apache 2.0 after a defined period.
• AGPL adds a network-use clause. If you run AGPL software as a service, you must release your modifications.
• Proprietary SaaS tools have no source to inspect. You operate through their API on their infrastructure under their terms of service.

The traditional open-source licenses

Apache 2.0, MIT, and BSD are what most engineers mean when they say "open source." They are permissive: you can use, modify, distribute, and sublicense the software with almost no restrictions. Attribution is required. Patent grants are included in Apache 2.0 (which is why enterprises prefer it over MIT for legal clarity).

These licenses let you do everything: self-host on your own hardware, modify and run the modified version, bundle the library into a commercial product without releasing your own code, or offer a managed version to your customers.

In the secrets tooling space, the 1Password CLI client (the op CLI) uses a mixture of proprietary server code and open-source client code. The CLI itself ships Apache 2.0 components. age (the encryption tool by Filippo Valsorda) is MIT. SOPS (Mozilla Secrets OPerationS, now maintained by the CNCF community) is also MIT.

For procurement: these tools are safe to embed, deploy, fork, and build on top of. The risk is operational, not legal. Permissive-licensed projects may move slowly, attract forks that fragment the ecosystem, or stop being maintained. The license gives you the freedom to carry on yourself, but that freedom has a cost.

Weak copyleft: MPL 2.0 and where it matters

Mozilla Public License 2.0 is called "weak copyleft" because the copyleft obligation applies at the file level, not the project level. If you modify an MPL 2.0 file and distribute the result, you must release that modified file under MPL 2.0. You do not have to release your surrounding code.

HashiCorp Vault used MPL 2.0 from its initial release in 2015 until August 2023. During that period, companies could self-host Vault, fork it, run a managed Vault service, and contribute back modifications to specific files while keeping their broader platform proprietary. OpenBao (the CNCF fork, discussed below) continues on MPL 2.0.

For secrets tooling, MPL 2.0 creates one practical constraint: if you fork Vault's storage backend (a single Go file, say) and ship that modification, that file goes back to the community. Your application code that calls the Vault API is not affected. Most companies never hit this boundary because they do not modify the tool's internals. They configure it. Configuration is not a code modification.

For procurement, the more pressing question is what changed in 2023 and why.

The source-available wave: BSL, FCL, and SSPL

Between 2018 and 2024, a cluster of infrastructure software companies moved away from open-source licenses. The pattern: a project gains adoption, a cloud provider offers a managed version without contributing back, the original company's commercial position weakens. The response was a new category of licenses designed to allow open source development habits while restricting competitors.

These are not open-source licenses under the OSI definition. They are "source-available": you can read and often run the code, but with conditions.

BSL: Business Source License

HashiCorp switched Vault, Terraform, Consul, and several other products to the Business Source License 1.1 in August 2023. The BSL has two key mechanisms:

First, the "Additional Use Grant" defines what production use is permitted for free. HashiCorp's grant allows use of Vault for non-competing purposes. Running Vault in your own infrastructure to manage your own secrets qualifies. Offering a managed Vault service that competes with HashiCorp Cloud Platform does not.

Second, the "Change Date" is a future date (typically four years from each release) when the license converts to an OSI-approved open-source license (Apache 2.0 in HashiCorp's case). Releases made in August 2023 convert in August 2027. The software becomes fully open-source eventually, but not now.

CockroachDB moved to BSL in 2019. Sentry moved to BSL in 2019 as well. These are not small projects and they made the move with careful legal framing. The practical effect for procurement: you can use these tools internally without restriction, but you cannot build a competing managed service on top of them.

The BSL also creates a community trust problem. When HashiCorp moved Terraform, the OpenTofu fork launched within weeks under the Linux Foundation. The fork carried the MPL 2.0 codebase forward. The community splintered. For secrets management specifically, OpenBao forked HashiCorp Vault at the MPL 2.0 codebase before the BSL transition, and continues active development.

FCL: Functional Source License

The Functional Source License is newer and narrower than BSL. It restricts use by "Competing Uses" (using the software to compete with the licensor's commercial offering) rather than restricting all production use by non-payers. The conversion period is typically two years to Apache 2.0, though specific projects may set four years.

FCL is designed to be more permissive than BSL for end users while still protecting the licensor from cloud-provider free-riding. An FCL-licensed secrets tool can be self-hosted, inspected, and even modified by any company that is not trying to sell a competing product.

hasp uses FCL-1.0 with a conversion to Apache 2.0 in 2027. As a procurement item: you can self-host it, inspect the code that handles your secrets, and deploy it inside your infrastructure without restriction, as long as you are not building a competing secret broker to sell to others.

SSPL: Server Side Public License

MongoDB introduced SSPL in 2018, and it is stricter than AGPL. If you run SSPL software as part of a service, you must release the source of the entire service stack, including your orchestration, provisioning, and management layers. The OSI rejected it as not meeting the open-source definition.

SSPL appears occasionally in the secrets tooling adjacent space (some database credential backends use MongoDB, for instance). It matters mainly if you are building a managed offering.

AGPL: the network-use clause

The GNU Affero General Public License adds one clause to GPLv3: if you run AGPL software over a network and users interact with it, you must provide those users access to the source code (including your modifications).

Infisical uses AGPL v3 for its self-hosted open-source offering, with a commercial license available for teams that need different terms. Under AGPL, you can self-host Infisical for your own team's secret management without any obligation to release your own application code. The restriction kicks in if you are offering Infisical as a service to third parties: you must release the Infisical source you are running, including any modifications. If you have not modified it, you link to the upstream repo.

For most engineering teams using Infisical internally, AGPL creates no practical friction. For companies building a secrets management product on top of Infisical, it is a real constraint and likely triggers a commercial license conversation with the Infisical team.

Proprietary SaaS: the black box problem

Doppler, AWS Secrets Manager, GCP Secret Manager, and Azure Key Vault are fully proprietary. No source to inspect, no on-premises option (AWS has a limited exception with AWS Secrets Manager on Outposts, but the core service is cloud-only), no ability to fork when the product is discontinued.

Three things follow from using fully proprietary tools.

You cannot inspect the code path that decrypts your secrets. You trust the vendor's security attestations, their SOC 2 reports, and their bug bounty programs instead of reading the implementation.

Your audit trail lives in their cloud. AWS CloudTrail captures Secrets Manager API calls, but those logs sit in your AWS account, which the vendor can access. GCP Secret Manager audit logs flow through Cloud Audit Logs in your project. The vendor has administrative access to the underlying infrastructure.

On-premises deployment is not possible. Regulated industries, air-gapped environments, and sovereignty requirements cannot use cloud-native-only secret managers unless you accept that secrets must leave the controlled network. AWS Secrets Manager on Outposts partially covers some edge cases, but the core service is cloud-only.

Lock-in is real. AWS Secrets Manager uses AWS KMS for encryption. Migrating off requires re-encrypting every secret under a different key in a different system. This takes planning, access control changes, and downtime windows across dependent services.

None of this makes proprietary SaaS the wrong choice for every team. For small engineering organizations without compliance requirements and heavy AWS dependency, AWS Secrets Manager is cheap, reliable, and requires zero ops overhead. The argument is about knowing what you are accepting, not that you should always avoid it.

License isn't always the most important thing

A team with five engineers, no compliance requirements, no air-gap, and AWS infrastructure everywhere should probably use AWS Secrets Manager. The license is proprietary, the audit trail lives in AWS, and none of those facts matter if your threat model is "please do not let a dev accidentally commit a key to GitHub." Secrets Manager solves that well and costs almost nothing.

The license conversation matters in four specific situations.

Your security posture requires you to inspect the code that handles secrets. You cannot audit a black box. Source-available licenses (BSL, FCL, AGPL) let you read the code at minimum. Open-source licenses let you run modified versions.

Your deployment environment prohibits external network connections. Air-gapped government networks, financial institution trading floors with outbound traffic controls, healthcare systems with strict data residency: none of these can use cloud-native SaaS.

You are building a product that includes secrets management as a feature. License compatibility matters here. AGPL creates friction for commercial embedding. Apache 2.0 does not.

You have been through a vendor license change and had to rebuild a deployment. HashiCorp moved Vault to BSL without a community vote. The tools you depend on can do the same. A license that starts as MPL or Apache can shift.

In each of those cases, the license becomes a deployment constraint, not a legal checkbox.

License matrix

The "self-host" column assumes you are not a competitor to the licensor. "Fork" means you can take the codebase and run a modified version internally. "Offer as SaaS" means you can build a managed service on top of it for external customers.

Procurement checklist

Paste this into a vendor evaluation document or PR description:

## Secrets tool license review

- [ ] Identified the exact license version (Apache 2.0? BSL 1.1? FCL-1.0?)
- [ ] Confirmed whether the license is OSI-approved open source or source-available
- [ ] Checked whether our deployment pattern (internal only, SaaS offering, embedded product) is permitted
- [ ] Confirmed whether on-premises or air-gapped deployment is possible
- [ ] Reviewed whether the vendor has changed licenses in the past three years
- [ ] Identified the conversion date if BSL or FCL (and what it converts to)
- [ ] Confirmed we can inspect the source code that handles secret decryption
- [ ] Checked whether the audit trail is under our control or in the vendor's cloud
- [ ] Confirmed the migration path if we need to switch vendors in 24 months
- [ ] Legal team reviewed the "Additional Use Grant" if BSL applies

What this means for your stack

The right license tier for your team depends on whether you need to self-host, whether your deployment needs to be auditable from source, and how much weight you put on "what happens if the vendor pivots again." For internal tooling with no air-gap requirement, proprietary SaaS is a defensible choice. For any environment where you need to read the code that decrypts production credentials, you need at least source-available.

hasp is one working implementation. curl -fsSL https://gethasp.com/install.sh | sh, hasp setup, connect a project, hand the next session a reference instead of a key. Source-available under FCL-1.0, converting to Apache 2.0 in 2027, local-first, macOS and Linux, no account, no cloud dependency.

The durable takeaway: whatever you pick, the license terms and the vendor's change history are both part of the decision. A tool is only as open as its least permissive version.