Dify可能不是开源软件？ | 从某医药公司收到Dify律师函说起

近日，Github上出现了一个“趣闻”

某医药公司在“使用”Dify期间的一系列操作，让许多开发者纷纷加入了吃瓜的行列

不过在吃瓜途中，大家又发现了一个问题：

Dify可能不属于“开源软件”

考虑到目前很多企业或独立开发者打算使用Dify来构建自己的AI应用或工作流

感觉还是有必要对其协议进行拆解分析一番

*本文仅为笔者个人观点，不视为任何法律建议或法律意见。

一、改资源还PR的某医药公司

Dify作为一款大语言模型(LLM) 应用开发平台，在国内可谓与Coze（扣子）各占低代码AI工作流半壁江山

尤其Dify还能本地部署且官方宣传“开源”，许多公司或独立开发者都会尝试用它部署一个本地AI服务后端

某医药公司也不例外

不过只是承担这个部署任务的员工有点“外行”

包括且不限于：

1. 把本地修改的东西推送到Dify主仓库并申请合并（Pull Requests，简称PR）

正常的使用方式应该是通过Git的克隆功能，克隆一份软件代码到本地进行修改并使用。而PR方式只适合于对开源软件的代码有优化、修复、新增功能等，属于协助（协同）开发的范畴。

2. 在提交的修改内容中包括了密钥文件

3. 泄露自家公共邮箱密码（导致疑似被盗号后，发送辱骂Dify全体开发者的邮件）

4. 当然，还有“开源之争”的导火索，改Dify的ICON

在各开发者围观下，Dify官方也迅速响应，委托自家合作的律所律师，对该医药公司发出了《律师函》，直指其使用方式违反了Dify的《开源协议》

不过正正是这份《律师函》，让开发者们重新审视了一下Dify在Github上发布的License

发现其可能并不“开源”

二、Dify可能并不符合“开源软件”定义

Dify分为了社区版、云服务版和商业版

其中社区版的代码放在了Github上，让公众自行部署并免费使用

不过，Dify并没有采用常见的开源协议，而是在Apache License 2.0上，“魔改”出了自己的版本

用DeepSeek翻译Dify最新版本的License结果如下：

可见，虽然Dify允许其他开发者用于商业化运营，但禁止多租户服务和禁止改ICON以及版权信息

不过，这两点可能已与开源协会（Open Source Initiative）对“开源”的定义相违背

多租户也是商业化模式的一种

何谓多租户？

“多租户”（Multi-tenant）是软件架构中的一个概念，指的是一个系统能够同时服务多个独立的用户或客户群体（即“租户”），而这些租户之间是相互隔离的；

“多租户”是一种常见的商业模式（比如SaaS服务）

而Dify在其协议中，则把Dify中一个工作空间定义为一个“租户”

如某用户创建多个工作空间，则会构成“多租户”使用，属于违反Dify授权协议

但开源协会对“开源软件”的定义中，明确要求不得限制软件在特定领域的使用，包括商业用途

Dify版协议中对某种商业用途进行了限制，明显已与该原则冲突

况且，Dify版协议对何谓“多个工作空间”实在语焉不详，究竟是“单个Dify后端不允许多个工作空间”，还是“不允许创建多个Dify后端形成多工作空间”

解释权全在Dify手中

LOGO严格意义上不属于版权文件

Dify在协议中限制用户修改/web中的logo图片和各类版权信息，其中web文件夹中的logo如下

在具体前端页面中，则大概体现在以下地方

根据开源软件定义，开源软件应允许自由修改和重新分发，包括衍生作品的创建

在创建衍生作品时，禁止删除版权信息是开源软件的常见限制，毕竟还是要保障原作者的署名权

但一般而言，如同原版的Apache License, Version 2.0，通常只需要在源代码（Source form）中保留相关的版权、专利、商标和归属声明即可

况且，LOGO通常更属于商标范畴而非版权范畴

Dify要求强制保留前端中的LOGO，实际上限制了用户对软件的完全自由修改权，如果用户需要基于Dify制作衍生作品，或希望将Dify集成到自己品牌产品时，则被迫只能保留Dify的LOGO（除非不用Dify的前端），强制为Dify打广告

一旦对LOGO进行修改，则会像这次某医药公司一样，被Dify“律师函警告”

三、Dify还能用吗？

公司内部部署Dify要注意什么？

首先要注意的是，不要Fork主版本下来，修改后PR到主仓库（笑~）

通常来说，公司内部自建Dify并使用问题不大

公司内部AI服务一般由IT团队（或者专职的AI服务人员）搭建，生成对应的开放接口或服务（比如一个网页聊天机器人），供员工日常使用

如果普通员工只是使用这些服务，不“自力更新”尝试在本机搭建Dify，一般不会构成Dify协议上的“多租户”问题

唯一的“小麻烦”是得接受Dify那无处不在的LOGO，需要忍住别手痒去源代码里替换这些图标文件

如果只是基于Dify的API另行开发应用，不直接调用Dify的前端页面，那连LOGO的顾虑都没有了

用Dify制作AI SaaS服务要注意什么？

谨慎

如果只是自建一些AI工作流，通过API提供给第三方用，勉强还能算符合Dify的协议

但如果是为多个第三方提供量身定制服务，分别为他们创建不同的工作空间（哪怕通过部署多个Dify社区版来实现），则必须要联系Dify团队购买商业许可

否则随时可能会因为违反协议，被Dify警告甚至起诉

另外，如果用Dify原生发布功能里的【嵌入网站】方式提供给第三方使用，还得注意不能动任何LOGO文件，一改就违规

还有一点需要额外留意

Dify协议里明确表示他们有权随时调整“开源”条款

因此如果想基于Dify构建商业服务，则需要更注重相关合规风险

建议定期检查协议是否变更，尤其是版本升级的时候

虽然一般来说协议变更不会追溯影响老版本，但要是没注意协议变动，不小心更新到了新版本，适用了新条款，那可能就会带来不必要的商业风险

四、番外：其实Dify有更好的处理办法目前Dify的争议主要来源于，虽然他们无论在Github还是文档中，都宣称自己是“开源的”，但实际其“魔改”的协议并不符合标准的“开源软件”规范

不过可以理解，Dify想利用“开源”扩大影响力（微软：这我熟），但核心盈利点仍在于云服务和商业授权版
一旦允许社区版自由魔改，必然会影响其自身的收益
不过，与其目前这样的“骑墙”做法，Dify还不如直接采用Business Source License（BSL）作为基础协议，设定一定年限（如3-5年）后自动转为Apache 2.0
BSL允许企业在初期限制商业竞争（如禁止直接用于SaaS服务），同时承诺未来回归开源社区。相较当前对Apache 2.0的魔改，BSL在业界已有成熟应用，更易被开发者接受，且能平衡短期商业保护与长期生态发展的需求
另外如果要保护自己的LOGO，避免被替换，还能考虑把前后端分离，前端采用附条件的商业授权，免费提供但禁止修改UI和LOGO；后端则使用BSL或Apache 2.0，保持代码的可修改性

这种方式既保障了后端的“纯开源”，又通过前端限制维护了Dify的品牌形象。相比现有协议将品牌保护（或者应该说是“广告条款”）混入技术许可的做法，分库授权更为规范且易于执行
不过想想，如果大家都自己搭建前端，Dify的LOGO又怎能遍布各处呢？

最后
用“开源”软件，还是要多留意“开源”协议