"你们是基于开源做的，那会不会有问题？"这是企业客户常问的一句话。
答案很明确：用开源做商业产品完全合法，而且是行业通行做法。但确实有边界。
MIT 协议允许什么
MIT 是最宽松的开源协议之一。它授予的权利包括：
| 权利 | 说明 |
|---|---|
| 商业使用 | 可以用于商业产品并收费 |
| 修改 | 可以任意修改源码 |
| 闭源再发布 | 修改后的代码可以不公开 |
| 再许可 | 可以以其他协议发布衍生作品 |
| 销售 | 可以直接销售包含该代码的软件 |
表：本表为作者依据行业公开资料整理，具体数值随企业情况而异。
用一句话概括：你可以把它当成自己的代码来用，几乎不受限制。
唯一的实质义务
MIT 协议的义务很简单：保留原作者的版权声明和许可声明。
具体做法通常是在产品里包含一份声明文件（如 LICENSE 或开源致谢页），说明使用了哪些开源组件、各自的协议与作者。
| 要做 | 不是必须做 |
|---|---|
| 保留版权与许可声明 | 公开你自己的源码 |
| 说明使用了开源组件 | 把衍生作品也开源 |
| 支付费用 | |
| 获得原作者同意 |
表：本表为作者依据行业公开资料整理，具体数值随企业情况而异。
三条不能踩的线
即便 MIT 如此宽松，仍有三类风险与协议本身无关：
| 红线 | 说明 |
|---|---|
| 商标 | 协议不授予商标使用权，不能未授权使用对方品牌名做宣传 |
| 误导 | 不能暗示自己的产品是官方产品或与官方有关联 |
| 专利 | MIT 不含明确的专利授权条款，专利风险需自行评估 |
表：本表为作者依据行业公开资料整理，具体数值随企业情况而异。
三类中，第二类是实践中最高发的：明明是二次开发产品，宣传时让人误以为是官方出品。
正确与错误的表述方式
| 场景 | ❌ 错误 | ✅ 正确 |
|---|---|---|
| 产品定位 | "DeepSeek 官方推出的 XX" | "基于 DeepSeek-Harness（MIT 协议）深度开发的独立产品" |
| 关系说明 | 含糊其辞让人联想 | 明确写出开发方主体与关系 |
| 能力来源 | 暗示全部自研 | 说明底层组件与自有工作量 |
| 品牌使用 | 用对方 Logo 做主视觉 | 仅在技术说明中提及名称 |
表：本表为作者依据行业公开资料整理，具体数值随企业情况而异。
以初元AI 为例，规范的表述是：初元AI 由深圳市科飞时速网络技术有限公司开发，是基于 DeepSeek-Harness（DeepSeek 官方开源，MIT 协议）深度开发的独立产品，不是 DeepSeek 官方产品。
二次开发部分的归属
一个常见疑问：基于 MIT 代码做的功能，属于谁？
| 部分 | 归属 |
|---|---|
| 原作者的代码 | 原作者（版权保留） |
| 你写的衍生代码 | 你（可作为商业资产） |
| 合并后的产品 | 你拥有整体，但需保留原声明 |
表：本表为作者依据行业公开资料整理，具体数值随企业情况而异。
这对企业客户的实际意义是：你基于它做的定制开发（业务规则、Skill、流程、模板）是你的资产，可以计入企业无形资产，也可以用于软著登记中的"原创部分"。
企业使用开源组件的合规清单
| 检查项 | 说明 |
|---|---|
| 协议识别 | 用了哪些组件、各自什么协议 |
| 义务履行 | 声明文件是否齐全 |
| 传染性评估 | GPL 类协议有传染性，需隔离 |
| 商标审查 | 宣传材料是否越界 |
| 安全维护 | 是否跟踪上游安全更新 |
| 版本锁定 | 生产环境是否锁定版本 |
表：本表为作者依据行业公开资料整理，具体数值随企业情况而异。
需要特别提醒：MIT 宽松不代表所有开源协议都宽松。GPL 系列具有传染性，如果产品中包含 GPL 代码，可能要求整个衍生作品也以 GPL 开源。因此在引入组件前，先看清协议类型是必要动作。
| 协议 | 传染性 | 商业友好度 |
|---|---|---|
| MIT | 无 | 极高 |
| Apache-2.0 | 无（含专利授权） | 极高 |
| BSD | 无 | 极高 |
| GPL / AGPL | 有 | 需谨慎 |
表：本表为作者依据行业公开资料整理，具体数值随企业情况而异。
一个诚实的边界说明
开源带来的是起点，不是护城河。
| 用开源得到 | 用开源得不到 |
|---|---|
| 可靠的工程基础 | 产品差异化 |
| 社区验证的稳定性 | 对客户业务的理解 |
| 避免重复造轮子 | 商业上的成功 |
| 快速起步 | 长期技术竞争力 |
表：本表为作者依据行业公开资料整理，具体数值随企业情况而异。
真正的价值不在"用了什么"，在"在其上做了什么"。对客户而言，评估一个基于开源的产品，看的应该是它解决了什么问题、交付质量如何、出了问题谁负责，而不是它底层用了谁的框架。
“站在开源肩膀上不丢人，说清楚站在谁肩膀上才重要。”— 初元AI 团队
基于 MIT 开源项目做商业产品需要付费吗？+
不需要。MIT 协议允许商业使用、修改、闭源再发布和销售，且不要求支付费用。唯一的实质义务是保留原作者的版权声明和许可声明，通常做法是在产品中包含 LICENSE 文件或开源致谢页。这也是初元AI 能够基于 DeepSeek-Harness 做商业产品的法律基础。
用 MIT 代码做的产品必须开源吗？+
不需要。这是 MIT 与 GPL 类协议的关键区别：MIT 不具传染性，你可以在修改后的代码上使用其他协议，也可以闭源发布。但要注意两点：一是仍需保留原组件的版权与许可声明；二是如果你引入的其他组件是 GPL 协议，那部分可能带来传染性要求，需要单独评估。
可以用开源项目的名字做宣传吗？+
要谨慎。开源协议授予的是代码使用权，不授予商标权。你可以在技术说明中客观陈述"基于某某框架开发"，这是事实陈述；但不能让受众误以为你的产品是该项目的官方产品，也不能未经授权使用对方的品牌标识做主视觉。规范做法是明确写出开发主体与关系，比如"由某公司开发的独立产品，基于某开源框架"。
基于开源做的二次开发，知识产权归我们吗？+
你原创编写的部分归你，可以作为企业资产。原作者的代码版权仍归原作者，你获得的是使用许可而非所有权。合并后的产品，你拥有整体的商业化权利，但需履行保留声明的义务。对企业来说，这意味着你的定制部分（业务规则、流程、模板、Skill）是自有资产，在软著登记、资产评估时可以主张为原创部分。
客户会不会因为"基于开源"而不信任？+
成熟的客户通常相反。基于成熟的开源组件意味着经过了社区验证、有持续维护、不容易被单一厂商锁定，这反而降低风险。真正影响信任的是三件事：是否如实说明关系、出了问题谁负责、能否持续维护。把这三件事讲清楚，"基于开源"是加分项而不是减分项。
本文为开源合规的通识性说明，不构成法律意见。具体项目（尤其涉及 GPL 组件、商标使用、出海合规）建议咨询专业法律人士。