SAFi Licensing Explained: Open Source Freedom with Built-In Governance

Organizations adopting open-source AI governance tools need more than access to source code. They need clarity about what they can modify, what stays private, and what they can honestly represent as an authentic deployment.

SAFi answers those questions through a licensing structure built on three commitments: openness of the core, sovereignty over your own configuration, and integrity of the governance loop itself.

SAFi's Core License: AGPL-3.0

The core architecture of SAFi is licensed under the GNU Affero General Public License, version 3.0, commonly called AGPL-3.0. Copyright is held by Nelson Amaya, 2025.

AGPL-3.0 supports broad use, inspection, modification, and redistribution. It also carries one requirement that matters for anyone running software as a service:

Any entity that modifies the core source code and makes it available over a network, for example as a cloud-hosted service, API, or SaaS product, must make their modified source code publicly available under the same license.

That provision keeps improvements to the governance core visible to everyone who depends on it. The full license text ships in the repository LICENSE file and is published by the Free Software Foundation at gnu.org.

One distinction worth holding onto: the Self-Alignment Framework itself, the philosophical and cognitive design vocabulary behind the software, is licensed separately for free use with attribution. The License and Governance Agreement covers the SAFi software implementation only.

What Stays Yours: The Organization Exception

Copyleft licenses raise a reasonable fear in regulated industries. If we deploy this, does our internal policy language become public?

No. Under Section 7 of AGPL-3.0, the copyright holder grants a special exception so that organizations can link, integrate, and run the SAFi core alongside private components without triggering the copyleft requirement on those components. The agreement names them directly:

• Charter and policy configuration data. Internal policies, rules, and value rubrics belong entirely to the implementing organization.
• Tools, knowledge bases, and plugins. Complete freedom to add, edit, or remove custom integrations.
• Branding and interface. Colors, fonts, logos, and custom deployment URLs.
• Authentication infrastructure. Identity management and network security configuration remain private.
• Help files. Customize the internal documentation for your staff or delete it.
• Database content and infrastructure. Runtime logs, audit trails, user data, policy records, and memory are the strict private property of the organization, along with the database and hosting choices behind them.

The exception holds on two conditions. The core loop files identified in Section II of the agreement are either left unmodified or, if modified for network deployment, published under AGPL-3.0. And the organization-specific components stay clearly separable from the core engine.

Core Engine and User Space

SAFi separates its code into two areas: the trusted core, the small and stable set of files responsible for the governance loop, and user space, the flexible layer where teams build interfaces, workflows, integrations, and extensions.

Work in user space is yours. You can modify it, extend it, and keep it private. Contributing changes back is welcome and entirely voluntary.

What Happens When You Modify the Core

An organization that changes core components and does not submit those changes upstream can keep running the software. The AGPL grants that right. What changes is representation. That installation becomes an independent fork, and it must be rebranded rather than presented as authentic or official SAFi.

This part of the agreement is governed by trademark law and the SAFi project's trademark policy. It sits separately from the copyright license and does not modify or expand any copyright obligation. Teams that want to modify core components and continue to identify the deployment as SAFi follow three steps:

1. Run the integrity check, scripts/verify_integrity.py, which ships with every SAFi release, including inside the container image.
2. Publicly commit and submit any reported core modifications for formal review.
3. Obtain formal acceptance from the SAFi project maintainers.

The check recomputes a SHA-256 hash of every core loop file, compares the result against the release manifest at scripts/core_integrity_manifest.json, and tests the structural invariants: no deterministic faculty reaches a model, and the staged governance sequence stays intact. It reports a single core-loop fingerprint that a deployment can cite as evidence of an unmodified core.

Why This Structure Matters

Most licensing debates trade one value against another. This structure holds two at once.

Organizations get real freedom to deploy, customize, and own their data. The wider community gets assurance that the governance core stays open when it is offered as a service, and that a system claiming to be SAFi is running the loop everyone can audit.

In a governance product, that second point is not a legal formality. The value of an audit trail depends on the integrity of the code that produced it.

A Practical Path for Organizations

For most teams, the shortest route is straightforward:

1. Run the released core without modifying it.
2. Build custom experiences and integrations in user space.
3. Keep policy, branding, tools, and data under the organization exception.
4. If core changes become necessary, submit them upstream for review.

SAFi's licensing structure is about more than permissions. It creates the conditions for open development, accountable customization, and justified confidence in the governance system your organization depends on.

This article is educational content, not legal advice. Review the applicable license and trademark terms with qualified counsel before deploying or modifying SAFi.

Sources: SAFi License & Governance Agreement, Developer Guide, and the core integrity manifest.