开放内核与授权许可

Olivares AI 是开放内核。完整的 Community 产品以 GNU Affero 通用公共许可证发布。 AGPL 构建包含整个治理平台，用户数量不限，支持一个活动身份提供商（IdP）。商用 enterprise/ 系列添加新的代码，仅在使用 -tags enterprise 时构建，不包含在公开二进制文件中。Business 将四个能力系列纳入一份订阅。Enterprise 的范围由合同约定。商业许可证提供 copyleft 的法律例外；任何已开放发布的功能都不会被移入付费版本。

授权边界

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

路径	授权许可	它是什么
`core/`	AGPL-3.0-only	引擎：摄取、事件总线、数据模型、模块运行时、API、授权、审计
`modules/`	AGPL-3.0-only	这 32 个模块（清点、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/`	商业	增量式模块，受构建标签门控，从不出现在公开二进制文件中（`LicenseRef-Olivares-Commercial`）

你正在阅读的这个文档站点是 AGPL 产品的一部分。哪项能力属于哪个版本，只在一处写明，即仓库中的 docs/editions.md；本页不再重复。

这对你意味着什么

自托管该产品（AGPL）。 你可以在 AGPL 下运行、研究、修改并再分发完整产品。AGPL 的网络使用条款适用：如果你通过网络向他人提供修改后的版本，你必须向他们提供你修改后的源码。对于内部自托管而言，这通常不成问题；如果你想在 Olivares AI 之上构建一款产品而不承担该义务，商业授权正是为此而设。
构建连接器（Apache-2.0）。 SDK 与连接器采用 Apache-2.0 —— 宽松、无 copyleft。你可以编写一个连接器、保持其专有，并以你喜欢的任何方式发布它。使这种做法安全的架构边界是强制执行的：Apache-2.0 连接器永远不导入 AGPL 引擎；它仅依赖于 SDK。这使得连接器生态系统免于 copyleft 带来的摩擦。
商业许可证。 需要 AGPL 义务例外的组织可联系 enterprise@olivares.ai。 Business 在一份订阅中包含以下四个能力系列。Enterprise 条款通过合同约定；各系列不单独销售。

版本与价格

版本	价格	范围
Community	免费，AGPL-3.0-only	用户数量不限；一个活动身份提供商（IdP）。
Business	每月 USD 99 或每年 USD 990	用户数量不限；一个法律实体；同一时间一个活跃实例。
Enterprise	联系我们	合同约定的条款及依赖这些条款的能力：多实体、更多部署或 IdP、隔离环境镜像、自定义 LTS，以及通过 OAuth 2.0 令牌交换（RFC 8693）签发的限定范围上游凭据。

Business 包含 Regulated Operations、AI Runtime Security、 Compliance Packs 和 Identity & Scale。每个系列保留自己的代码和许可证权益边界。你可以启用或停用各系列；它们不单独销售。私有实现以商业二进制文件分发，位于公开仓库之外。

可以单独购买某个能力系列吗？

不可以。上述四个系列均包含在 Business 订阅中。在价格页面选择按月或按年付款。

如果需要同时运行多个活跃实例，该怎么办？

请联系 enterprise@olivares.ai 商议 Enterprise 范围。Business 许可证同一时间只能在一个实例上生效；你可以在一个实例上释放它，并根据需要在另一个实例上激活。Enterprise 支持多个同时活跃的实例。

何为开放、何为商业

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

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

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

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

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

为何选择这一模式

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

贡献

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