奇 奇连 AI
学习路线图课程工具计算器企业服务关于加入会员

Macro 的 AGPL-3.0 协议与自托管边界：官方仓库和文档到底写了什么

2026-08-17

搜到这篇的人，多半卡在同一个地方：Macro 挂着”完全开源”的牌子，仓库根目录写着 AGPL-3.0，于是自然会想——那我能不能拉下来自己部署一套？改了之后要不要开源？拿它做二次开发卖给客户会怎么样？

这些问题的答案分两层。第一层是事实层：官方在 README、CONTRIBUTING 和文档站 FAQ 里究竟白纸黑字写了什么。这一层可以查、可以核，本文就干这件事。第二层是法律判断层：某个具体做法在某个具体司法辖区下合不合规、你的改动算不算”衍生作品”、要不要开源。这一层本文一概不下结论——那属于法律判断，请咨询专业人士，并以官方许可证原文（仓库里的 LICENSE.txt）为准。

我把这两层分开写，是因为网上关于 AGPL 的讨论经常把二者混在一起：拿别人博客里的结论当法条，再套到自己的场景上。对自托管这种一旦跑起来就很难回退的决定，这么干风险不小。

仓库里关于许可证只说了三句话，但每句都有信息量

README 的 License 一节篇幅很短，核心信息是三条：

第一，Macro 是完全开源，官方特意强调”不是 open core”，采用 GNU Affero General Public License v3.0，细节以 LICENSE.txt 为准。open core 指的是开源一个功能受限的内核、把关键能力留在闭源商业版里；官方主动划清这条界限，等于是在说仓库里的代码就是产品本身，而不是删减版。

第二，你可以在 AGPLv3 的条款下自托管 Macro，README 直接把读者指向文档站 FAQ，说那里讲了”这件事具体涉及什么”。这个指路本身就说明官方认为自托管不是拉个 Compose 就完事的。

第三，留了两个不同用途的邮箱。想在 Macro 之上做二次开发但不想用 AGPLv3（也就是想闭源，或者想用一个与 AGPL 不兼容的许可证）的，联系 licensing@macro.com 谈另一份许可；想要托管服务或商业合作的，联系 self-host@macro.com。

FAQ 里把这层商业逻辑讲得更直白：Macro 的收入来自两块，一是自家托管版（跟其他 SaaS 一样收钱），二是那些要在 Macro 上做二次开发、又不愿意接受 AGPLv3 的客户付费购买另一份许可。这就是典型的双许可模式——开源版本和商业授权是同一份代码的两种拿法。

还有一个时间点值得记下来：官方 FAQ 写明，Macro 此前是 BSL 下的 source-available（源码可见但不算开源），2026 年 5 月 31 日才切换到 AGPLv3 的完全开源模式。如果你手上有更早的克隆或者更早时间点的资料，许可条款是不一样的，别拿旧的当新的用。

至于”AGPL 的 copyleft 意味着衍生作品也要开源”这句——官方 FAQ 自己是这么表述的，我如实转述；但你的具体改动算不算衍生作品、触没触发开源义务，这属于法律判断，本文不下结论，请咨询专业人士并以官方许可证原文为准。本文也不打算逐条解释 AGPL 的条文，那既超出我的能力范围，也超出这篇文章该干的事。

官方原话：自托管可以，但明确说了不是当前重点

FAQ 里”能不能自托管 Macro”这一条，答案是”可以，在我们的 AGPL 许可下”，但紧接着有一个很关键的限定：截至 2026 年 6 月，自托管一直不是官方的主要投入方向。

这句限定后面跟着一串具体的落差，我按 FAQ 的表述整理成表：

事项托管版的情况自托管你要自己面对的
iOS App托管版可用，且已拿到 Apple 的相应审批官方说明 iOS 应用是与托管版配套的
Gmail 集成托管版持有 Google Mail 的审批相应审批不随代码转移
GitHub PR 集成托管版持有 GitHub 审批同上
基础设施官方托管在 AWS，维持 SOC 2 Type II 审计你自己的合规状态与官方审计无关
视频通话官方转授权 LiveKit需自行维持相应服务授权，或关闭该功能
身份认证官方转授权 FusionAuth同上
数据分析官方转授权 PostHog同上

最后三行是我认为最容易被低估的一块。Macro 不是一个纯自研的单体，它转授权（sublicense）了若干第三方服务：视频通话用 LiveKit、认证用 FusionAuth、分析用 PostHog 等等。FAQ 明确说，自托管方”得自己维持这些服务的授权，或者把它们关掉”。也就是说，AGPL 只解决 Macro 自身代码的使用问题，解决不了这些第三方依赖的商业授权问题——你要么自己去谈、自己付费，要么接受功能残缺。

官方还给了两条后续路径：一是他们”希望在今年（2026 年）晚些时候把精力转到让自托管更容易”上，这属于官方标注为计划中的事项，目前尚未提供；二是 FedRAMP 场景以及其他需要把 Macro 跑在自有基础设施上的客户，可以直接联系 self-host@macro.com，官方会协助落地。

还有一条容易被误读的补充，FAQ 特意澄清了：自托管并不是满足 HIPAA 或欧盟数据驻留的前提条件——托管版本身就签 BAA，也提供欧盟境内托管。换句话说，如果你考虑自托管的动机只是合规，官方的意思是先去看托管版的安全页面，不一定非走自托管这条路。至于具体到你所在行业和地区的合规要求能不能被满足，这仍然属于法律与合规判断，本文不下结论。

想进一步了解自托管前要准备什么，可以看 Macro 自托管的本地跳起步骤 和 Macro 自托管常见的坑；如果你还在权衡到底走托管版还是自建，Macro 的计费规则 那篇整理了官方公开的口径。

想在本地跑起来，官方指的是这两份文档

README 把”跑起来”和”参与贡献”分成了两条路：完整应用跑在自己机器上，看 docs/RUNNING_LOCALLY.md；要提交代码，看 CONTRIBUTING.md。

对判断自托管难度有帮助的，是 README 给出的仓库结构：

macro/
├── apps/
│   ├── web/       SolidJS client — browser, Tauri desktop, mobile
│   └── docs/      docs.macro.com
├── services/      42 deployable services, workers, and Lambda handlers
├── crates/        167 Rust libraries — domain logic, models, db clients
├── packages/      shared TypeScript — collaboration, lexical-core, loro-mirror
├── infra/         Pulumi definitions
├── docker/        local Compose stack
├── nix/           pinned dev shell and build inputs
└── tooling/       repo scripts and code generators

42 个可部署服务、167 个 Rust crate，加上 Pulumi 写的基础设施定义，这个量级本身就说明了运维成本在哪一档。docker/ 目录下有本地 Compose 栈，nix/ 里是钉死版本的开发环境——但”能在本机 Compose 起来”和”能对外提供生产服务”之间隔着多远，官方文档没有给出承诺，我也没有实际部署过，不做估计。服务采用六边形架构布局（入站适配器 / 带端口的领域内核 / 出站适配器），约定写在 docs/STYLE_GUIDE.md。

改了代码想推回上游：贡献者协议这一段是硬约束

自托管方迟早会改代码，改完想不想推回上游是另一回事，但 CONTRIBUTING 里有一条必须提前知道：提交贡献即表示你同意你的贡献以 AGPLv3 授权，与项目本身的许可证一致。

流程上的硬要求也很明确：

  • 先开 issue 再提 PR，功能和修复都一样。官方给的理由是先确认这个改动是否被需要、方案是否合适，免得白干。没有关联 issue 就冒出来的 PR，可能会被直接关掉。
  • 允许用 AI 工具，但不接受未经审阅的 AI 产出。原文的要求是：你得把自己的改动和决策理解到能在 review 里答得上问题的程度，并且要在本地开发环境里看到改动确实跑通了。直接把模型输出原样丢上来，官方说这是浪费 reviewer 时间，会被关闭。
  • 命名走 Conventional Commits。PR 标题格式是 type(scope): short description，合并后会成为 commit message；分支名同理，用斜杠分隔，例如 feat/chat-dev-observability。常用类型是 feat、fix、chore。
  • PR 正文自己写、写简短：改了什么、为什么改、关联 issue、reviewer 需要知道的东西。官方明确不要生成式套话，也不要逐文件罗列改动清单。

推送前的检查项在文档里是具体命令：

cargo fmt
just clippy
cargo test -p <crate>
just prepare_db

前两条对应 Rust 改动的格式化与 lint，第三条只跑你动过的 crate 的测试，最后一条是在改了 SQL 查询或迁移之后，在仓库根目录刷新 sqlx 缓存。这几条命令对自托管者同样有参考价值——哪怕你不打算推回上游，改完 Rust 代码后至少知道该跑什么才不至于把编译期校验的 SQL 弄坏。

顺带一提，FAQ 里也回应了”是否接受外部贡献”：接受，直接在 github.com/macro-inc/macro 开 PR；不知道从哪儿下手的，可以邮件问 teo@macro.com。

一个容易发错的细节：两个邮箱不是一回事

README 和 FAQ 里出现了三个不同用途的邮箱地址，混着看很容易发错人：

邮箱官方说明的用途
licensing@macro.com想在 Macro 上做二次开发但不用 AGPLv3（闭源或不兼容许可证），谈另一份许可
self-host@macro.com托管服务、商业合作；FedRAMP 等需要跑在自有基础设施上的客户
security@macro.com安全问题上报，官方称按严重程度和影响支付赏金

如果你的诉求是”我要改一版闭源的卖出去”，那是许可证问题，走第一个；如果是”我需要它跑在我自己的机房里”，走第二个。两者在实际商务谈判中会不会合并处理，文档没写，我不做推测。

这篇没解决什么

说清楚边界比堆结论重要，所以最后单列一节：

不给法律意见。 你的场景是不是触发了 AGPL 的开源义务、内部使用算不算”分发”、给客户提供网络服务算不算触发 AGPL 的网络条款——这些都是法律判断，本文不下结论，请咨询专业人士并以官方许可证原文为准。我也刻意没有逐条解释 AGPL 条款，网上那类”三分钟看懂 AGPL”的文章，拿来当决策依据是危险的。

不给部署难度评估。 我没有安装、没有运行过 Macro，所以关于自托管要多少机器、多久能跑通、哪一步最容易卡，一个数字都不给。仓库结构里那 42 个服务和 167 个 crate 是官方写的，怎么换算成你的运维成本，得你自己按环境估。

第三方依赖的授权成本未知。 LiveKit、FusionAuth、PostHog 各自的商业授权怎么算钱，不在 Macro 的文档范围内，官方只说了”你得自己维持或者关掉”。这部分要去各家自己的定价页确认。

自托管的官方支持进度未知。 官方标注为计划中的”让自托管更容易”，目前尚未提供，也没有给出具体时间表，只说了”希望在 2026 年晚些时候”。在这件事落地之前，把自托管当成一条官方尚未铺平的路来对待更稳妥。

如果你还没搞清楚 Macro 到底是个什么形态的产品，建议先看 Macro 是什么 再回头判断自托管这件事值不值得。

延伸阅读

本文依据 Macro 官方仓库（github.com/macro-inc/macro，AGPL-3.0 协议）的 apps/docs/ 产品文档、 MCP 工具参考与自托管说明整理，核对日 2026-08-17。 我们没有注册或运行过 Macro，因此不涉及界面外观与操作手感； 官方标注为计划中的能力文中已如实标明，不代表当前可用。 价格与额度以官网 macro.com 最新页面为准；许可证相关问题请咨询专业人士并以官方许可证原文为准。

想系统学会用 AI？报名体系课或加入会员，照着学、照着用。

浏览课程 加入会员