你维护着一个有用的开源远程访问项目，担心云厂商复制并作为托管服务提供却不回馈贡献。这样的情形——所谓的 SaaS 漏洞——正是一些团队选择 AGPL 的原因。
你维护着一个有用的开源远程访问项目，担心云厂商复制它、将其作为托管服务提供并且不回馈贡献。这种情形——所谓的 SaaS 漏洞——正是一些团队选择 AGPL 的原因。本文解释了 AGPL 对 SaaS 运营者实际产生的作用、它如何影响变现选择，以及真实的运维权衡，包括中继托管和托管与自托管部署的差别。
通俗理解：AGPL（Affero GPL v3）带来什么变化
AGPLv3 是在 GPLv3 基础上增加网络使用条款（通常称为第13条）的版本，要求你向通过网络与程序交互的任何人提供源码。实际上这意味着：如果你运行一个 AGPL 应用的服务器端，而用户通过网页或 API 与其交互，你必须向这些用户提供你所修改的源码。它弥补了经典的 GPL “SaaS 漏洞”——公司可以修改代码、以托管服务运行却从不发布改动。
这种法律效力是狭义且具体的。它不会神奇地阻止别人托管你的软件，但它创造了一个共享改动的法律义务，并在第三方将你的代码重新打包为专有托管产品时，给原授权方提供可用的杠杆。
AGPL 如何支持 SaaS 商业模式
在三个实际的商业模式中，AGPL 对 SaaS 支持明显：
- 双重许可：将代码以 AGPL 授权给社区，同时向需要在不受 AGPL 约束下嵌入或扩展代码的客户出售商业（专有）许可。这是数据库和中间件厂商常见的开源商业模式。
- 托管增值与托管基础设施：将核心协议/代码以 AGPL 保持开源，然后出售在运维上难以低成本复制的托管服务——多区域中继、分析、备份或编排等。客户为便利性、SLA 和降低运维负担付费。
- 支持、SLA 与企业功能：AGPL 代码保持开源，但你通过付费支持、培训、定制集成或从独立服务边界提供的专有企业插件来变现。
对于远程桌面软件来说，托管中继是自然的产品形态：中继承担带宽，并且需要全球部署以保证低延迟。销售托管中继在商业上是合理的，同时客户端和服务器代码仍可保持 AGPL。
双重许可：机制与现实
双重许可在概念上很直接：你在 AGPL 下发布项目，同时向不希望接受 AGPL 义务的客户提供商业许可。两个关键的实施点是对贡献者代码的控制和法律上的明晰。
贡献者控制：要出售商业许可，你需要干净的著作权转让或贡献者许可协议（CLA），以允许你重新授权贡献者的代码。没有这些，你无法合法地出售包含第三方贡献的专有许可。
商业定价：预计早期的商业许可更可能通过谈判达成而不是直接列价。许多项目从一个透明定价的简易托管产品开始（例如，中继服务）——Tenvo 的托管中继就是将运维部分打包销售的例子——而更深度的集成或本地部署则保留谈判定价。
为什么托管中继通常是默认推荐
运维复杂性是自托管的隐形成本。一个中继集群需要 TLS 证书管理、监控、DDoS 保护、多区域故障切换、带宽计费和值班工程师。对于大多数商业客户来说，购买托管中继能减少时间到价值并带来可预测成本。
Tenvo 的托管中继默认提供多区域，并捆绑在我们的商业计划中：Free $0，Lite $2.99/mo 和 Pro $7.99/mo。对于想要简化并获得 SLA 的团队来说，托管中继通常在考虑到补丁、事件响应和证书生命周期后，花费低于雇佣一名全职运维人员。
自托管：何时是正确的选择
当书面要求强制这么做时，自托管绝对是正确的选择：禁止第三方基础设施的法规、没有互联网出口的隔离网络，或你的托管中继无法满足的严格数据驻留要求。在这些情况下，AGPL 仍然可行——甚至可能更合适——但你必须接受运维成本：部署、HA、事件响应、密钥保管和 TLS 证书续期。
如果你在评估自托管，请阅读我们在 Self-hosted remote desktop: the honest 2026 guide 中的实操权衡——文中逐步讲解了 DNS、证书自动化和不能省略的基础监控。
安全与加密：许可不会改变的东西
许可不会改变传输安全的事实。从架构上看，直接 P2P 连接在两个设备之间是端到端的。如果会话回退到中继，TLS 必须在中继处终止，因此中继运营者有能力观察会话流量。这是你在销售托管基础设施或客户询问数据暴露时必须考虑的运维事实。
在产品说明中要明确说明这一点：描述何时可以建立直接连接、回退到中继意味着什么，以及中继运营者能和不能访问哪些内容。想深入了解远程桌面威胁，请参阅 Remote Desktop Security: What You Need to Know。
实用架构：将可变现部分与核心分离
选择 AGPL 时，应把打算变现的组件与 AGPL 许可的核心分离开来。常见的拆分模式：
- 开放核心：客户端和协议核心在 AGPL 下；可选的专有服务器组件（例如高级编排 API）以商业许可或 SaaS 形式提供。
- 服务边界：将托管中继和运维服务置于独立服务中，通过已文档化的 API 与开源核心交互。中继可以是专有的或作为收费服务提供，而核心仍然保持 AGPL。
- 插件与核心：将运行时、协议和低级传输保留在 AGPL 下；暴露扩展点以便企业插件（商业许可）能在受控环境中运行。
架构上的分离减少法律模糊性，也更容易向客户解释哪些部分是开源的、哪些是商业服务。
开发者与社区权衡
AGPL 会吸引那些支持强烈 copyleft 和社区改进的贡献者，但也可能让拒绝网络使用义务的公司望而却步。你应该预期来自构建专有 SaaS 公司的拉取请求会更少——但个人开发者和机构的社区贡献往往更积极，因为他们知道代码将保持开源。
为保持贡献健康，准备清晰的贡献文档、如果计划双重许可则采用 CLA，并公开治理规则。许多项目采纳透明治理政策、固定发布节奏（例如每月稳定版 + 每夜构建）以及明确的安全披露流程，以降低企业用户的摩擦。
执法与声誉——软杠杆
许可的有效性取决于你能否执行它们。执法可以是法律途径，但通常是声誉上的：公开点名、礼貌沟通和社区压力都很重要。开源生态中高关注度的变动（例如一些数据库厂商转向 SSPL 或 source‑available 许可证）表明许可选择会驱动行为——但执法需要资源以及准备好走上或靠近诉讼的意愿。
如果执法对你的模式至关重要，请做好准备：保留贡献历史，跟踪部署者（在法律允许的范围内），并为法律支持预留预算。对许多项目来说，AGPL 的实际价值在于威慑作用和通往谈判的明确路径，而不是经常性的法庭诉讼。
价格与成本示例：现实核算
实际数字各异，但在选择托管与自托管中继模型时，可以参考以下粗略示例：
- 小团队使用单一区域中继且带宽负载轻：托管中继在 <$100/月 的情况下通常比投入运维时间去运行并保护它更便宜。
- 生产级服务需要多区域 HA 和 24/7 值班：复制、DDoS 保护和出口带宽会把自托管成本推高到数百或数千美元每月。考虑到人员成本，带 SLA 的托管中继可能更具成本效益。
这些只是大致范围——容量、出口流量和合规要求会迅速改变预算——但要点是：可靠的全球中继的运维成本并不低，这也是将其打包为付费服务有经济合理性的原因。
清单：负责任地发布基于 AGPL 的 SaaS
- 明确选择许可版本（多数团队推荐 AGPLv3）并记录其覆盖范围。
- 如果计划出售商业许可，使用 CLA 或著作权转让。
- 将可变现的基础设施（中继、编排、分析）置于明确的服务边界之后。
- 记录会话何时经过中继以及安全含义（TLS 在中继处终止）。
- 发布清晰的升级、安装和加固文档，以降低自托管者的摩擦。
- 决定执法姿态，并为法律资源或调解政策预留预算。
- 为托管服务制定透明分层价格；Tenvo 的 Free $0 / Lite $2.99/mo / Pro $7.99/mo 模型是一个简单入门渠道并可扩展到带 SLA 的企业计划的例子。
何时选择其它方案
如果你的目标是让第三方 SaaS 厂商最大化采用，或者希望在闭源系统中无须谈判地宽松复用，AGPL 可能不是正确选择。对于打算被嵌入到专有产品中的库，宽松许可证（MIT/BSD/Apache 2.0）通常更合适。
也可以考虑混合方案：一个宽松的客户端库配合 AGPL 的服务器，或宽松核心配合 AGPL 的参考服务器。每种选择都清楚地传达了你希望鼓励或限制的复用类型。
更多阅读与比较
如果你想对远程桌面项目的权衡进行比较，我们的派生与托管比较文章值得一读： RustDesk vs Tenvo: fork comparison for self-hosters 。如果你在做自托管的成本/收益决策，请重新查看 Self-hosted remote desktop: the honest 2026 guide 中的运维步骤。
许可只是众多杠杆之一。当你需要法律保证网络用户可以获取源码并且打算通过运维服务变现时选择 AGPL，但要明确告诉客户 AGPL 能解决和不能解决的问题：它处理的是代码贡献与披露，而不是传输安全或配置错误。
准备好尝试带有托管中继选项的 AGPL 支持远程访问堆栈了吗？下载客户端进行试验，或在 our pricing page 查看定价详情和托管计划。想亲手操作时，前往 download，几分钟内测试一个中继支撑的部署。