DeepSeek的开源协议和商用许可说明

开源模型的许可问题，向来是商业落地中最容易“踩坑”的环节。DeepSeek 这一系列模型——从 V2、Coder 到 R1 系列——虽然关注度很高，但商用前的许可核验，远没有“MIT 或 Apache 2.0 就完事了”那么简单。现实情况是：权重、代码、API 接口和训练数据，四者的许可可能是完全独立的，并非统一打包。

最需要明确的一点：DeepSeek 的最新开源模型（如 DeepSeek-V2、DeepSeek-Coder、DeepSeek-R1 系列权重）

。商用之前，务必逐一核验每个组件对应的 LICENSE 文件。所谓“MIT”或“Apache 2.0”标签，通常只覆盖部分组件，而非整个模型分发包。这个拆分设计说明一件事：只看模型卡上的协议名，远远不够。

DeepSeek-Coder 的 Apache 2.0 只保你改代码，不保你用权重

以 DeepSeek-Coder-6.7b 为例，它在 Hugging Face 上明确标注了 Apache-2.0。但这里的协议约束对象，是配套的 modeling_deepseek.py、configuration_deepseek.py 等源码文件，并不是 .safetensors 权重本身。这意味着什么？

• 你可以修改推理逻辑、重写 tokenizer、甚至把模型嵌入闭源 IDE 插件里——代码层面的修改，Apache 2.0 确实允许。
• 但权重文件的实际分发页面（比如 deepseek-coder-6.7b-base）底部，往往另附一个 DeepSeek License 1.0 链接，这才是真正管商用的主协议。
• Apache 2.0 本身要求保留 NOTICE 文件中的归属声明。漏了 NOTICE，或者删了注释里的 Copyright (c) 2025 DeepSeek AI，就已构成违约。

换句话说，代码好改，权重不好碰。Apache 2.0 的标签在这里更像是一个“局部的保障”，而不是全栈通行证。

DeepSeek-R1-Distill-Qwen 系列的“MIT”是权重层许可，底座仍是 Apache 2.0

社区蒸馏版本，比如 DeepSeek-R1-Distill-Qwen-1.5B，在 Hugging Face 模型卡里标注的是 MIT。但请注意，这仅指其发布的 pytorch_model.bin 权重文件受 MIT 约束。底层复用的是 Qwen-1.5B 架构，而 Qwen 最新仓库明确采用 Apache License 2.0。

所以你实际要合规的动作，远不止一个 MIT 声明那么简单：

• 在产品 LICENSE 文本中，必须同时包含 MIT 声明（针对蒸馏权重）和 Apache 2.0 声明（针对 Qwen 底座）。
• 不能略掉 Qwen 的专利授权条款说明。Apache 2.0 明确授予用户使用 Qwen 相关专利的权利，但该授权仅限于“执行本许可证授权范围内的行为”。
• 如果在蒸馏过程中使用了 DeepSeek-R1 API 输出，需要自查其 Terms of Service 是否禁止用于训练。目前最新 ToS 并未明文禁止，但没有书面豁免，就意味着存在灰色风险。

这个双重许可结构，在实际部署中很容易被忽略——尤其是当团队只盯着最表层的“MIT”标签时。

DeepSeek-OCR-2 和 DeepSeek-VL 的 MIT：不等于“随便封装成 SaaS”

DeepSeek-OCR-2 确实做到了全栈 MIT 协议——权重、训练脚本、vLLM 集成代码都覆盖。但这不表示你可以直接开个 ocr.deepseek-api.com 收费接口。关键限制在于：

• MIT 确实不禁止 SaaS，但 DeepSeek-VL 等多模态变体在模型卡中额外注明“禁止将模型直接封装为 SaaS 并对外提供原始推理接口”。这是 Custom License 条款，优先级高于 MIT。
• OCR-2 的 MIT 允许你卖私有化部署包，但若客户要求你托管服务，你就变成了“服务提供方”。此时需要遵守 DeepSeek 正式《Model License Agreement》第 4.2 条：日志留存 ≥ 90 天，并配合审计。
• 所有 MIT 版本都强制要求：在软件 About 页面、安装包 LICENSE 文件、甚至 Docker 镜像元数据中嵌入完整版权声明。少一个换行符，都算违规。

最容易被忽略的陷阱，其实是“分发场景”的定义。把模型集成进内部工具，不对外发布二进制？这仍然属于 MIT/Apache 规定的“分发”。用 vLLM 启动服务，客户通过内网调用？只要请求经过你的服务器，就已经触发了许可义务。协议看的不是有没有“卖钱”，而是有没有“传递副本”。这一点，值得反复确认。