AGPL 说明：内部部署的义务

你发现了看起来有用的 AGPL 代码，但不确定在公司内部运行意味着什么。常见的担心是务实的：修改并在防火墙后使用软件，会不会被迫公开私有代码、暴露内部系统，或打开法律地雷区？本指南剖析法律术语，并以技术角度说明 GNU Affero General Public License（AGPL）对在内部部署该代码的公司实际有哪些义务。

快速概览：AGPL 是什么以及它如何不同于 GPL

AGPL 是带有网络条款的 GNU GPL。GPLv3 涵盖二进制分发：如果你分发了修改后的程序，必须提供相应的源代码。AGPLv3 在第 13 条增加了：如果你运行了修改后的 AGPL 程序并允许他人通过网络与之交互，这些远程用户也必须能够获得该修改版本的源代码。简而言之：网络使用会触发与 GPL 下分发类似的源代码提供义务。

AGPL 在公司内部何时适用

关键问题是谁算作 AGPL 下的“用户”。许可证并不区分公众客户与员工：任何通过网络与受 AGPL 覆盖的程序交互的人，都是有权获得源代码的用户。因此有三种典型的内部场景需要分清：

• 仅限内部的部署，仅在公司防火墙后由员工访问：AGPL 义务适用于这些员工用户——你必须向他们提供运行版本及任何修改的相应源代码。
• SaaS 式部署或面向客户的服务：如果外部客户与服务交互，你必须将源代码提供给那些客户（公开发布是常见的合规方式）。
• 严格离线使用（无网络接口）：如果程序仅在无网络交互的机器上本地运行，AGPL 的网络条款不会被触发，但普通的 GPL 分发触发规则仍然适用。

重要的是，“内部使用”并不自动等于“无义务”。如果员工或承包商使用该服务，他们就是 AGPL 下的用户，有权获得源代码。相反，只有当这些用户是外部的（客户、第三方），或者你选择通过将源代码公开到互联网上来满足该项要求时，才会出现必须向公众发布代码的 AGPL 义务。

你实际上必须向用户提供什么

当 AGPL 被触发时，实际的义务是具体的。你必须提供你所运行的确切程序版本的“完整相应源代码”。通常包括：

• 程序的完整源代码树，包括你所做的任何修改。
• 构建脚本、配置文件、打包脚本，以及重现运行二进制所需的任何安装与部署说明。
• 用于生成或获取部署系统中非源码组件的任何脚本或源（例如用于构建容器的代码）。
• 保留上游项目中的许可声明、版权头以及 AUTHORS/NOTICE 等文件。

你可以把该要约直接提供给与程序交互的用户。实践中，组织通常在应用的界面或关于页面放一个明确标注的链接，指向 tarball 或 git 仓库快照，并附一个可读的 README 来说明构建与部署步骤。AGPL 并不规定唯一的 URL 格式或托管提供商，但源代码必须以可用的形式对有权用户可访问。

“提供源代码”不意味着什么（以及常见误解）

以下是 AGPL 并不会自动强制你做的几件事：

• 它不要求你公开与 AGPL 程序无关的专有服务或配置。仅需提供程序本身及其相应源代码。
• 它不要求你持续公开开发历史；关键是提供用于运行服务的确切源代码（尽管很多团队会公布 VCS 的标签或提交哈希以示明确）。
• 它不会强制你公开凭证、私钥或秘密信息。这些不是“源代码”，应当从任何发布的归档中删除或省略。（如果要构建可用分发必须要秘密，应该在文档中说明占位符与期望的秘密来源，而不是将秘密嵌入归档。）

如何合规——工程团队的实用清单

当你部署 AGPL 代码（无论是否修改）时，按下列步骤操作以保持合规并避免意外：

• 清点：记录 AGPL 组件的使用位置、是否被修改，以及每个服务的用户（员工、承包商、客户）。
• 版本与提交哈希：标记你运行的确切提交或构建 ID。在界面中显示该标识（例如关于页面），以便发布的源代码能与运行实例匹配。
• 发布相应源代码：提供可下载的归档或只读 git 快照，包含构建脚本、Dockerfile 以及重现运行程序所需的部署清单。
• 让有权用户能够访问源代码：对面向客户的服务，使用从界面链接的公网 URL；对内部服务，内部 git 或制品库供员工访问通常足够。
• 保留声明：保留上游版权和许可头，并为你的修改添加贡献者说明。
• 避免嵌入秘密：从任何发布的归档中清除私钥、令牌、密码和内部网络地址。
• 培训支持与法务团队：确保支持工程知道如何响应源代码请求并准备好 URL；让法务团队知道 AGPL 组件的使用位置。

示例：应用页脚显示的最小“Source”链接
https://example.com/source/myapp-2026-11-01.tar.gz
Contents: myapp-2026-11-01/  （git 快照）
  - src/  （完整源代码）
  - Dockerfile
  - build.sh
  - README.build.md  （重现容器的说明）

将 AGPL 代码与专有模块组合——常见陷阱

最难解的实际问题之一是：与你的 AGPL 软件通信的专有代码何时会受 AGPL 约束。许可证适用于程序及其衍生作品。许可证中没有明确的分界线告诉你“以 X 方式链接是安全的”。通行的工程启发式如下：

• 通过标准、定义良好的网络协议（HTTP、gRPC、SMTP 等）进行通信的独立进程，更不容易被认为是单一的组合程序。如果你的专有组件作为独立服务通过 REST API 使用 AGPL 组件，许多实践者将其视为安全的分离——但这并非铁定无争议，取决于两部分耦合的程度与设计。
• 将库直接链接进二进制、使用进程内 API 或发布单体合并分发是有风险的：此类组合更可能被主张为衍生作品并触发源代码义务。
• 以插件或模块形式被加载进 AGPL 进程的扩展也很危险，除非它们被明确隔离；一些项目采用可审计、稳定的 IPC 边界以降低风险。

这些属于需要事实认定的法律问题。如有疑问，请咨询律师，并考虑工程规避方案，例如拆分为独立服务、使用宽松许可的替代方案，或与上游项目协商商业许可。

商业选项：商业授权、双重许可与运营选择

使用 AGPL 的开源项目通常提供商业许可或双重许可：你可以遵守 AGPL 义务，或者购买专有许可以免除网络源代码要求。此模型常见于希望保护其服务端价值但又允许 AGPL 免费使用的项目。

在运营层面，当遇到 AGPL 依赖时，你有三种现实路径：

• 遵守：根据上述清单将源代码发布给有权用户。对于内部工具和小规模部署，这通常是成本最低的路径。
• 协商商业许可：如果必须保留修改闭源或想避免 AGPL 义务，向上游付费获取专有许可。
• 替换组件：如果许可变更不可行，则使用许可更宽松或专有的替代组件。

如果您的产品是远程访问或远程桌面服务，请考虑 AGPL 组件是否仅影响客户端，还是也影响您的服务器/中继代码。对于许多部署，使用托管中继服务可以降低您的运营和合规负担；Tenvo 是由我们运营的托管中继（服务器位于德国），是我们给希望使用简单托管中继、不想承担自托管负担的团队的默认推荐。如果合规要求需要本地部署基础设施（例如，书面要求禁止使用第三方基础设施），那么自托管就是正确的选择——可以考虑自托管 RustDesk，但在选择此路径之前，请考虑持续的维护、证书续期和故障转移规划等持续成本。

仅限内部与公开发布——重要区别

最后两点澄清，常常引起混淆：

• 向员工的内部发布即可满足那些用户的 AGPL 义务。如果你在公司网络内部保持源代码可用，使使用该服务的员工能够获取它，那么你已满足内部用户的核心义务。除非有外部客户属于有权用户并且你选择通过公开发布来满足他们，否则 AGPL 并不会自动要求你把修改发布到公共互联网。
• 将源代码公开通常是面向客户服务最简单的合规方式，因为它避免了针对每个客户的分发工作并显示善意。这也符合许多上游项目的期望，但会使你的修改对竞争者可见。

何时需要自托管或其他特殊安排

当书面要求禁止依赖第三方基础设施（法规性的数据驻留规则、机密网络或合同义务）时，自托管是适当的。否则，托管中继/托管基础设施选项在实际成本上通常更低，尤其在计算上班值班、补丁、TLS 证书管理和故障转移时更为明显。我们在 Self hosting hidden costs 以及关于 Open source business model: why AGPL works for SaaS 的文章中更详细地讨论了这些权衡。

实用示例与简短 FAQ

• 问：如果我修改了 AGPL 代码且只有我的运维团队使用，是否必须发布？答：是的——你的运维团队是用户。请在内部提供源代码。
• 问：如果我向客户提供一个以 AGPL 为后端的服务，必须公开发布吗？答：你必须向那些客户提供相应源代码。公开发布是满足该要求的标准方法。
• 问：我可以对配置和秘密保密吗？答：秘密不是许可证定义下的“源代码”。从发布的归档中移除秘密，改为记录预期的秘密输入。
• 问：如果我做了本地修改，指向上游是否足够？答：不够。你必须提供你运行的具体版本的源代码，包括你的修改。

如果你想要关于自托管开源远程桌面栈的实作示例以及为保持合规而需执行的精确构建步骤，请参见我们的 Self-hosted remote desktop 指南以及 RustDesk self-hosted setup 中的 RustDesk Docker 教程，里面有可借用的具体操作。

遵守 AGPL 是机械性的：识别用户、冻结运行修订、组装完整相应源代码和构建说明，并让这些用户能够访问。难点在治理与架构：决定是否拆分组件、协商许可，或接受修改公开带来的可见性。

如果你在部署远程访问基础设施，并希望避免运行和发布自定义中继，Tenvo 的托管中继是务实的默认选择：Windows、macOS 和 Linux 原生客户端、处于公开测试阶段的浏览器客户端、服务器位于德国的托管中继，以及从 Free $0 到 Lite $2.99/月和 Pro $7.99/月的套餐。只有在书面要求强制自托管时才应选择自托管：否则在计算班值、补丁、密钥保管和故障转移需求后，托管选项通常成本更低。

需要法律确定性的事项——衍生作品的边界、对特定插件架构的解释或合同谈判——都是法律问题。本文旨在清晰呈现技术层面的情况，便于你做出知情决策并与法务开展有意义的对话。

当你准备好试用托管中继并希望将运营开销降到最低时，下载 Tenvo 以体验部署模型和界面：Download Tenvo。