可持续开源：PinConsole 的 AGPL-3.0 与商业授权实践

维持一个开源项目很难。数据是众所周知的：94% 的开源维护者是无偿的。拥有数百万用户的项目依赖于少数人的业余时间。精疲力竭是常态。

标准的可持续性方案有几种常见的路径：

• 捐赠（Open Collective、GitHub Sponsors）——对某些领域有效，但很少能覆盖一个人的薪水 • 托管服务（WordPress.com、GitLab）——你运行你 OSS 项目的 SaaS 版本 • 双许可（MySQL、MongoDB）——AGPL 用于开源，商业许可用于专有使用 • 咨询和支持（Red Hat 模式）——围绕开源产品售卖专业知识

PinConsole 走双许可路线，但有一个不同之处：我们有意识地将商业许可基础设施保持到最低。没有许可服务器、没有销售团队、没有自动密钥生成。只是一个电子邮件对话。

原因如下。

AGPL-3.0 许可是这个模式的基础。快速回顾它的工作原理：

如果你按原样使用 PinConsole 进行你自己的内部运营——监控你自己的网站、协助你自己的访客——AGPL 除了保留许可声明外不强加任何义务。你可以部署它、为内部使用修改它，无需分享一行代码。

AGPL 只在两种情况下激活：你向他人分发修改版本，或者你作为网络服务向第三方提供该软件。著名的"网络使用即分发"条款（第 13 条）填补了标准 GPL 留下的 SaaS 漏洞。

这就是我们选择 AGPL 而非 MIT 或 Apache 2.0 的原因。云服务商不能拿走 PinConsole，包装成 SaaS 产品，与开源项目竞争而不分享其修改。这个许可证防止了商品化。

但关键在于，AGPL 本身并不创造收入流。它只创造了一个边界。收入机会来自商业许可——一份针对无法或不愿遵守 AGPL 要求的组织的单独协议。

PinConsole 的商业许可非常简单。它不是有层级、定价页面或功能门控的产品。它是一个对话。

如果你的组织需要：

• 将 PinConsole 嵌入你分发给客户的专有产品中 • 以 AGPL 的版权要求造成合规摩擦的方式使用 PinConsole • 为采购或法律要求签署一份商业协议

你给维护者发邮件。我们讨论你的用例。我们达成对双方都有利的条款。你获得一份明确允许你的用例的许可。项目获得资金。

没有功能分层。商业许可涵盖与 AGPL 版本相同的软件——相同的代码、相同的能力、相同的单一二进制。区别在于法律条款，而非软件本身。

这种简单性是刻意的。构建许可服务器、实现密钥验证、维护客户门户——这些是消耗本来应该用于产品本身的时间和注意力的基础设施。对于 PinConsole 当前阶段的项目来说，正确的模式是"先把软件做得很好，等它能养活自己了再考虑企业销售基础设施。"

许多具有商业许可的开源项目需要贡献者许可协议（CLA）。这赋予项目维护者在商业许可下重新许可贡献的权利。

PinConsole 没有 CLA。没有贡献者协议、没有版权转让、没有提交 pull request 所需的额外文书工作。

这是一个刻意的选择。CLA 为贡献者制造了摩擦——尤其是首次贡献者。它们需要法律审查、签署基础设施，以及"我需要许可才能贡献"的心理模型。对于一个希望建立社区的项目来说，这种摩擦是一种成本。

这种权衡是真实存在的：没有 CLA，我们不能在未经贡献者个人许可的情况下将社区贡献重新许可到商业许可下。如果有人贡献了一个重要功能，如果商业被许可人需要在商业条款下使用该功能，我们需要回头找他们。

在实践中，这还不是一个问题。对商业被许可人直接有用的贡献通常属于基础设施级别的改进（更好的性能、安全修复、部署增强）——这些类型的更改在被要求时，贡献者很乐意双许可。而且因为商业许可对话是一封个人邮件，而不是一个自动化系统，请求许可是很自然的。

如果未来商业许可和社区贡献的数量增长到个人许可请求成为瓶颈的程度，我们可能会添加 CLA。但在需要之前，我们不会添加。

对于大多数开源项目来说，单靠商业许可不足以产生维持全职开发的收入。真正的机会是许可对话之后随之而来的咨询和实施服务。

当一个组织询问商业许可时，对话自然引向：

• "我们如何在生产环境中部署这个？" • "你能帮我们定制共浏览行为吗？" • "我们需要与 SSO 供应商集成——这个在路线图上吗？" • "你能为高可用性审查我们的部署架构吗？"

这些对话才是真正的价值。商业许可是门——咨询参与是房间。

这种模式很好地对齐了激励。维护者有直接的经济激励来让 PinConsole 变得更好、更易于部署、对组织更有价值。而这些组织获得了一个为他们的特定问题定制的、生产就绪的部署——而不仅仅是一个他们自己下载和配置的二进制。

并非每个开源项目都能走这条路。它只在维护者拥有组织愿意付费的领域深度专业知识时才有效。对于 PinConsole——一个替代 $500+/月工具的免费自托管方案——这种专业知识具有明确的经济价值。

对于双许可项目的一个担忧是开源版本变成了"残废"的试用版——有限的功能、缺失的能力、刻意的摩擦。

PinConsole 不这样做。AGPL 许可的版本是完整产品：

• 无限会话——没有每会话上限 • 无限运营人员——没有按座定价 • 全部功能——会话回放、实时监控、共浏览、聊天、弹窗 • 全部存储后端——PostgreSQL、Redis、MinIO • 全部集成——SDK 配置、小组件自定义、管理 API

没有"企业版"对社区版本隐藏功能。没有隐藏的定价页面。AGPL 版本和商业许可之间的唯一区别是你使用相同代码所依据的法律条款。

这既是哲学选择也是实际选择。PinConsole 的存在是因为我们相信自托管会话回放应该对每个团队都是可及的——而不仅仅是那些有企业预算的团队。AGPL 保护了这一愿景，同时允许需要不同法律条款的组织为项目的开发提供资金。

开源许可格局近年来发生了显著变化。以下是 PinConsole 的方法与其他方法的比较：

**MongoDB SSPL（服务器端公共许可）。** 在 AWS 将 MongoDB 作为托管服务提供而不做任何回馈后创建。SSPL 比 AGPL 更进一步——如果你将 MongoDB 作为服务提供，它要求你将整个"管理层"（监控、备份、自动化）在 SSPL 下许可。这比 AGPL 更具保护性，但尚未获得 OSI 批准，并与其他开源项目产生兼容性摩擦。PinConsole 坚持使用 OSI 批准的 AGPL-3.0。

**Elastic License (ELv2)。** Elastic 从 Apache 2.0 迁移到一种源可用许可，限制用于"托管服务"和"SaaS 产品"。非 OSI 批准，严格定义上不是开源。我们更喜欢 AGPL——它是真正的开源、OSI 批准，并实现了相同的实际效果。

**BSL（商业源许可）。** MariaDB 的模式——在变更日期（通常 3-4 年）后从限制性许可转换为 GPL 的开源代码。对于希望商业许可有有时间限制的独占窗口的项目很有吸引力。在某些方面比 CLA + 双许可更简单，但增加了许可版本追踪的复杂性。

**MIT + SaaS 服务。** 一些项目对开源代码使用 MIT，并通过托管 SaaS 版本盈利（GitLab、WordPress）。这在项目具有网络效应或转换成本使得竞争对手无法以更低价格提供相同 SaaS 时有效。对于会话回放，转换成本很低——任何云提供商都可以将 MIT 许可的 PinConsole 作为 $5/月的服务提供。AGPL 防止了这种情况。

对于 PinConsole，AGPL-3.0 + 商业许可是正确的平衡：OSI 批准、法律上标准、有效防止 SaaS 商品化，且没有自定义许可的复杂性。

我相信在开源商业层面保持透明。

在撰写本文时，PinConsole 处于早期阶段。商业许可基础设施是最低限度的——与评估该项目的组织进行了少量对话。项目由以下方式维持：

• 直接开发工作（构建组织需要的功能） • 咨询参与（部署、定制、培训） • 商业许可费用（针对需要不同法律条款的组织）

可持续性不需要数百万的 VC 资金。它需要覆盖开发、基础设施和维护者时间的成本。对于一个没有云基础设施成本的自托管工具，门槛很低。

目标不是最大化收入。目标是构建一个团队可以实际使用的会话回放平台，在尊重他们对其数据自主权的条款下——并在长期持续这种开发。AGPL-3.0 配合务实的商业许可路径实现了这一点。

如果你正在为你的组织评估 PinConsole 并对许可有疑问，给我发邮件。对话就是产品。