开放内核与授权许可

Olivares AI 是开放内核。完整产品以 GNU Affero 通用公共许可证发布，而 AGPL 构建就是整个治理平台 —— 从不为了把你推向付费版本而从内部削弱它。在其之上是一小组增量式商业附加组件，位于 enterprise/，仅在使用 -tags enterprise 时构建，且不出现在公开二进制文件中。商业授权提供对 copyleft 的法律例外；enterprise/ 的能力则作为单独的可选附加组件授权 —— 因此开放版与商业版并不完全相同，但任何已开放发布的内容都不会被移到付费墙之后（这是 GitLab 的 ee/ 模式，而非对内核设置功能付费墙）。

授权边界

授权许可与源码目录树保持一致。每个文件都带有 SPDX 头部，且该边界在 CI 中强制执行（连接器永远不得导入引擎）：

路径	授权许可	它是什么
`core/`	AGPL-3.0-only	引擎：摄取、事件总线、数据模型、模块运行时、API、授权、审计
`modules/`	AGPL-3.0-only	这 30 个模块（清点、R/RW 访问图、FinOps、评估、护栏……）
`web/`	AGPL-3.0-only	React 界面
`sdk/`	Apache-2.0	连接器/模块接口、gRPC 契约与共享类型
`connectors/`	Apache-2.0	各类连接器（Claude、OpenAI、pgAudit、eBPF、云、Slack、SIEM……）
`enterprise/`	商业	增量式附加组件，受构建标签门控，从不出现在公开二进制文件中：多 IdP 联邦、内容防火墙/DLP、Hook 加固、编译的威胁情报目录、服务器端工具出口、CyberArk Conjur、事件闭环（`LicenseRef-Olivares-Commercial`）

你正在阅读的这个文档站点是 AGPL 产品的一部分。

这对你意味着什么

自托管该产品（AGPL）。 你可以在 AGPL 下运行、研究、修改并再分发完整产品。AGPL 的网络使用条款适用：如果你通过网络向他人提供修改后的版本，你必须向他们提供你修改后的源码。对于内部自托管而言，这通常不成问题；如果你想在 Olivares AI 之上构建一款产品而不承担该义务，商业授权正是为此而设。
构建连接器（Apache-2.0）。 SDK 与连接器采用 Apache-2.0 —— 宽松、无 copyleft。你可以编写一个连接器、保持其专有，并以你喜欢的任何方式发布它。使这种做法安全的架构边界是强制执行的：Apache-2.0 连接器永远不导入 AGPL 引擎；它仅依赖于 SDK。这使得连接器生态系统免于 copyleft 带来的摩擦。
商业授权。 需要规避 AGPL 义务的组织（例如将产品嵌入专有产品中）可获得商业授权 —— 请联系 enterprise@olivares.ai（价格请垂询）。上述增量式 enterprise/ 附加组件单独授权，每一个都是可选的权益。

何为开放、何为企业

开放二进制文件就是整个治理平台；enterprise/ 产品线是增量式的。有两条边界值得专门点明，因为开放构建会就它们诚实地作答，而非假装它们不存在：

SSO —— 单 IdP 登录（OIDC + SAML 2.0）在默认二进制文件中是开放的：真实登录，无需 -tags enterprise。多个活动 IdP（按租户/按域名）、SSO 强制执行与托管式 SCIM 属于保留的企业产线；启用第二个活动 IdP 会返回 multi_idp_requires_enterprise。
用户账户 —— 在所有版本中都不受数量限制。社区构建没有用户上限，企业构建同样没有：任何授权状态（有效、过期、缺失）都无法限制一个部署可运行的账户数量。 2026-07-27 之前存在的三个活动账户上限已被彻底移除；席位接缝仍作为兼容性 no-op 保留在代码中，但不会拒绝任何操作，授权过期也绝不会限制、停用或删除账户。

完整的开放与企业对照请参见诚实与限度。

授权密钥从不对开放产品设限

这一点很重要且是有意为之的：在开放（AGPL）二进制文件中，授权验证仅作为存证。引擎记录谁持有该授权及其状态；它从不因一次授权检查而禁用、降级或阻止任何请求、任何模块或启动过程，并且它离线运行（一个 Ed25519 签名，无授权服务器），这正是该开放产品能在气隙（air-gapped）环境下工作的原因。授权被消费而非仅被展示的唯一场所，是封闭的企业构建，且仅用于授予商业协议所涵盖的附加组件的权限，并逐个附加组件评估 —— 这是商业版中的一项本地决策，而绝非开放二进制文件中的检查。它绝不限制用户数量：账户在所有版本中都不受限。因此开放构建确实是完整的、不受授权限制的；商业版中有所不同的，是那些增量式的 enterprise/ 附加组件，而非一把授权密钥在同一个二进制文件内开关功能。

为何选择这一模式

对内核设限的做法被否决了：开放版能完成全部工作 —— 在单个节点上跑完整套治理闭环 —— 所以对它设限只会使其成为一个更差的产品并侵蚀信任。全面宽松授权（在内核上采用 MIT/Apache）会把内核拱手让人却无任何商业立足点。源码可见但非 OSS 的授权（BSL、SSPL 及类似授权）会扼杀开源采纳，而开源采纳正是一个可扩展连接器生态系统的全部意义所在。于是这一模式便是开放内核：一款自身即完整且可信的 copyleft 产品，一套让连接器生态系统免于摩擦的宽松 SDK，以及一小条由全新代码构成、从未出现在开放构建中的增量式商业产品线 —— 外加一项干净的商业例外 —— 同时从不削弱你可以自托管的内容。

贡献

贡献依据项目的贡献条款被接纳（代码仓库同时提供 DCO 与 CLA，外加一份商标政策）。当前流程请参见代码仓库的 CONTRIBUTING 指南。