谁说开源就能随便商用？Dify、n8n、CrewAI 的 LICENSE 里藏着最大的坑
选 Agent 平台，大部分人只问两句：能不能自托管？贵不贵？
问到第三层就露馅了——它到底是个开源软件，还是个”源码可见”的东西？
这区别在 GitHub 上看不出来。一堆项目挂着 open source 的旗子，LICENSE 第一行写的是「Apache 2.0 附加若干条件」。翻到第三条发现：禁止多租户、禁止去掉 LOGO。那这还叫开源吗？我把主流横向 Agent 平台的 LICENSE 扒了一遍，结论比想象的扎心。
一张图先看懂分层
这张图的纵轴是授权强度递减。你站的位置，决定了你能干什么。
第一层：纯闭源 SaaS——Zapier 和 Make
Zapier 应用生态 8000+，Make 3000+（各家口径略有出入，量级在那儿）。两家都没有自托管方案，数据必须过对方服务器。这不是缺点，这就是商业模式——付订阅费，买的是”不用运维”。
但拿它做生产，心里得有数：你没有任何代码所有权。哪天涨价、限流、改 API，都是别人说了算。个人折腾够用，想当公司基础设施，趁早清醒。
第二层：源码可见受限——这层最坑
共同特征是：GitHub 上能看到全部代码，能自己 Docker 跑起来，但 LICENSE 里埋着限制条件。
n8n（20.6 万星）用的是 Sustainable Use License，官方文档写得很直白：按 OSI 的定义，带使用场景限制的协议不算开源，所以他们自己都不叫自己 open source，管这叫 fair-code。内部自建随便用，但不能拿它开 SaaS 收费、不能打包转卖。仓库里还有个 LICENSE_EE.md，带 .ee. 的文件不在社区协议内。
Dify（15.78 万星）更有意思，协议叫”Apache 2.0 附加条件”，条件挺要命：
- 禁止多租户——除非 LangGenius 书面授权，你不能拿它跑多租户环境。而”一个 workspace 就是一个 tenant”这个定义写得明明白白。要做 SaaS 就踩线。
- 禁止去掉 LOGO——前端（
web/目录或 Docker 的 web 镜像）里的版权标识不能改。纯后端调用不受此限。 - 还有一条最有争议：贡献者代码可能被用于官方云业务的商业用途，且官方保留单方面改协议的权利。
AutoGPT（18.76 万星）玩目录分级：autogpt_platform/ 里是 Polyform Shield License，禁止对外分发；外面的经典 Agent、Forge 是 MIT。同一仓库两套协议，抄代码前先看清自己在抄哪个文件夹。
第三层：真开源——Langflow 和 CrewAI
Langflow（15.55 万星）是干净的 MIT，CrewAI（5.93 万星）也是。MIT 意味着什么？自托管、二次开发、改成自己的样子、贴牌卖给别人，法律上都没问题，只要保留版权声明。
只做内部使用，第二三层差别不大。但只要动了”卖出去”的念头，就老实待在第三层。
第四层：看着正常，其实有坑
AutoGen（6.12 万星）的坑很隐蔽。GitHub API 报的协议是 CC-BY-4.0——一个内容许可，不是软件许可。但仓库根目录还有第二个文件 LICENSE-CODE，里面才是标准 MIT。也就是文档归 CC-BY，代码归 MIT。你写脚本自动读协议做合规检查，读到的是 CC-BY，然后得出”这不是可商用软件许可”的错误结论。
它更大的问题是生命周期：README 顶部挂着橙色徽章写着 Maintenance Mode，微软自己说”不会再有新功能，社区维护，新用户请用 Microsoft Agent Framework”。上生产的话，这信号比协议本身更致命。
MetaGPT（7.07 万星）是干净的 MIT，但最后提交停在 2026 年 1 月，144 个 issue 没人动。这不叫协议问题，叫项目心跳问题。
Flowise（5.55 万星）的教训最典型：仓库已在 2026 年 8 月被官方归档。代码还在，但没人维护。协议允许你做的事，和项目还活着，是两回事。
动手前的三步自查
第一步，打开仓库根目录的 LICENSE 原文，别看 GitHub 侧边栏那个标签——它可能只反映其中一个文件。
第二步，找有没有 .ee. 或 enterprise 目录。n8n 和 Flowise 都有，那部分代码不在主协议内。
第三步，问自己：这东西我要拿去卖吗？ 只是自用，第二三层随便挑；想商用、改品牌、做多租户 SaaS，老实选 MIT 协议的项目，或者买官方商业授权。
实话
这类”改过的开源协议”是开源生态里最尴尬的存在。OSI 创始人早就因为 Elastic 改协议跟 Elastic 打过嘴仗，最后”开源定义”里加了一条：不得歧视使用场景。你看到的 fair-code 模式，本质是厂商在”保住大部分好处的同时，把最赚钱的托管服务圈起来”。
我不是说它不对。 厂商要活下去，收商业授权费天经地义，Dify 和 n8n 的产品确实做得比大多数开源方案好。问题在命名——你叫它 fair-code、叫它 source-available，甚至叫它”modified Apache”，但用户第一次看到时，它挂在那个蓝色盾牌下面，以为自己能改能卖能贴牌。等到真拿去商用被追责，那个锅用户背。
还有个很多人不看的细节：Dify 的 LOGO 限制。”我做个内部工具，LOGO 留着又怎么了”——那没问题。但哪天你想白牌出去卖给客户，这条就会卡死你。协议里每一条，都是在某个场景下咬过人的。
选型看协议，别只看星数。6 万星但已进维护模式的 AutoGen，和 7 万星但 MIT 清晰、只是更新变慢的项目，你选哪个？
本文数据（星数、协议、提交时间、issue 数）均于 2026 年 10 月 4 日直接核对 GitHub API 与各项目 LICENSE 原文。
by 数码罗记 · godsun.pro
