开源许可证与合规实操：从MIT到GPL，如何避开法律风险

最近后台隔三差五就有人来问我：“我项目明明写了 MIT License，为什么合规检查还是挂了？”“老板让我把公司软件开源，许可证到底该选哪个？”“GitHub 上复制了一段代码放进商业项目里，会不会出事？”

这些问题看起来是技术问题，实际上全是法律和政策问题。而国内专门把这摊事讲透的资料并不多，所以当我看到 COSCon‘25 期间要办“木兰技术开放日”，而且要围绕《开源法律、政策与实践》这本书做共读活动、发布完整议程的时候，说实话还是挺兴奋的。这属于那种“早该有人认真做，但一直没人系统做”的事。

这篇文章我尽量不写成会议通告，而是站在一个常年接触开源项目、也帮团队踩过合规坑的从业者角度，把这本书、这次议程、以及背后真正值得关注的开源合规实操，一次性讲清楚。不管你是刚准备开源第一个项目的个人开发者，还是公司里负责开源治理的合规负责人，这篇都值得花十分钟看完。

1. 为什么开源圈突然要“共读”一本法律书？

1.1 开源项目遍地都是，但法律问题没人讲

从最近各个平台的热搜关键词就能看出来，开源已经不再是极客圈的小众话题。“开源鸿蒙 PC 版下载”“开源大模型”“开源 OA 系统推荐”“GitHub 开源项目推荐”“清华大学开源软件镜像站”……这些词背后是大量普通开发者和企业在主动拥抱开源。

但另一条线同样刺眼：“关于开源软件合规排查”“Black Duck 扫描自动提示”“Gitee 开源许可证选什么”。一边是疯狂使用开源组件，一边是对许可证条款毫无概念。我见过不少项目，README 写得漂漂亮亮，LICENSE 文件却压根不存在；也见过公司把一个 GPL 组件静态链接进商业软件，直到收到法务通知才慌慌张张开始排查。

这就是为什么《开源法律、政策与实践》这本书值得被拿出来共读。它不是一本纯法学教材，而是把开源世界里散落的规则、协议、案例、政策，整理成了普通人能读懂的体系。共读的意义在于：一个人啃法律条文很容易半途而废，但一群人带着问题读，读完之后还能在现场交流，效果完全不一样。

1.2 这本书到底讲什么，跟普通开发者有什么关系

先给没接触过的朋友一个基本画像。《开源法律、政策与实践》涉及的内容大致包括四个方向：

• 开源许可证的条款拆解与法律性质分析，比如 MIT、Apache-2.0、GPL 系列背后分别意味着什么；
• 开源基金会和社区治理规则，比如基金会为什么存在、项目捐给基金会之后版权和商标归谁管；
• 企业开源合规体系建设，包括依赖管理、代码扫描、合规审计、对外开源流程；
• 开源相关政策与发展趋势，包括各国对开源的态度、标准制定、开源供应链安全等。

很多开发者觉得“我只写代码，法律离我太远”，但现实是：你在 GitHub 上 fork 一个项目、给项目提 PR、把别人的代码复制进自己的仓库、在 README 里用了某个项目的 logo，这些动作每一件都有法律含义。共读这本书最大的收获，不是让你成为律师，而是让你知道“什么动作有风险、风险大概在哪、出事了该找谁”。

1.3 木兰技术开放日是干嘛的，议程有什么看点

木兰技术开放日不是一个新的会议品牌，它脱胎于木兰开源社区，是围绕开源治理、许可证合规、基础设施等方向做专题交流的线下活动。这次放在 COSCon‘25 期间举办，议程围绕《开源法律、政策与实践》展开，是个很聪明的组合：COSCon 提供流量和人群，木兰提供专业度和议题深度。

从已经公布的议程形式来看，共读会、圆桌讨论、法律合规工作坊、开源治理案例分享这几类基本都齐了。我个人最期待的是案例拆解类的环节，因为法律条文读起来是一回事，真遇到具体场景怎么判断才是真正的经验壁垒。如果你也想参加，建议提前把书翻一遍，尤其是第三章许可证、第五章合规实务这类核心章节，带着问题去现场收获会大得多。

2. 共读这本书之前，先把基础概念捋清楚

2.1 许可证的本质：一张附条件的授权合同

很多开发者把开源许可证当成一个“标签”，觉得代码放上 GitHub 就等于可以随便用。这是最大的误区。

许可证的本质是一份合同，作者通过它向使用者授予版权许可，但这份许可是附条件的。你使用、修改、分发、商用代码，都必须满足许可证里写明的条件。比如 MIT 许可证的核心条件是“保留版权声明和许可声明”，Apache-2.0 额外要求“如果你修改了文件，要有明确的修改记录”，GPL 则更进一步，要求你的衍生作品必须同样以 GPL 方式授权。

用生活里的例子来类比：房东把房子租给你，和把房子送给你，完全是两码事。许可证就是房东写的“租房合同”，上面写清楚了你能住几间房、能不能养宠物、能不能转租。你拿到代码之后“住”进去之前，第一件事应该是读合同，而不是先搬家具。

2.2 常见开源许可证横向对比

我把最常见的几种许可证整理成一张表，方便你和团队对照：

选许可证最怕的就是“跟风”。个人项目图省事可以选 MIT，但如果你希望别人使用你的代码后把改进贡献回来，就考虑 Apache-2.0 或 MPL；如果你的目标是做基础设施，不希望别人拿去闭源改造，那就用 GPL。企业项目则要额外考虑法务团队的接受度，不是技术负责人一个人拍板的事。

2.3 木兰系列许可证到底是什么水平

国内开发者对木兰许可证应该不陌生，尤其是木兰宽松许可证第二版（MulanPSL-2.0），是目前国内开源项目里使用比较多的协议之一。

木兰宽松许可证在条款设计上对标 Apache-2.0，但它的特点在于中文版的表达更清晰，条款数量也更精简，同时通过了 OSI（开放源代码促进会）认证，是真正意义上的国际认可开源许可证。对于国内团队来说，用好木兰系列能降低理解和沟通成本，同时也避免了很多翻译不准确带来的歧义。

这次共读活动专门围绕中文语境下的开源法律与政策来展开，木兰系列许可证作为典型案例，大概率会是讨论重点。我觉得无论国内开发者还是海外项目维护者，都值得关注这块内容，毕竟许可证的本地化不是简单的“翻译”，而是一整套法律表达体系。

3. 从“共读”延伸到实操：开源合规自查清单

3.1 一个开源项目的合规四件套

读书是输入，动手做合规才是输出。不管你是个人作者还是企业维护者，一个合规的开源仓库至少应该包含四样东西：

• LICENSE 文件：明确许可证全文，不要只写许可证名字，要把协议原文放进去。
• NOTICE 文件：如果项目基于其他开源代码修改而来，或需要额外声明版权归属，NOTICE 里要写清楚。
• README 中的许可证说明：说明项目采用什么协议，以及使用者需要注意什么。
• CONTRIBUTING 文件：向贡献者说明授权方式（比如 DCO 或 CLA），避免后续版权归属争议。

很多个人项目只放一条 README 就完事，这在法律上相当于“保留所有权利”，别人就算看到你的代码也不敢用。想要被开源社区放心使用，这套文件必须补齐。

3.2 企业做开源合规的流程

企业用户踩的坑和个人完全不是一个量级。个人顶多是被要求删除代码，企业一旦违规，面临的可能是商业谈判中的筹码损失甚至诉讼。一套基本的企业开源合规流程大致是这样：

1. 建立开源组件台账：引入任何开源组件之前先登记，记录组件名、版本、许可证、URL。
2. 依赖来源审查：确认组件来自官方仓库或可信镜像，避免引入恶意篡改版本。
3. 许可证扫描与冲突检测：用工具自动识别依赖树中的许可证，检查是否存在 GPL 传染、许可证互斥。
4. 合规评估与例外申请：如果检测到高风险许可证，提交给合规委员会评估，必要时走例外审批流程。
5. 对外发布前的审计：对外发布 SDK、应用或容器镜像之前，做一次全量扫描。
6. 定期复扫：依赖一升级就可能导致新增许可证，需要周期性重新扫描。

这套流程听起来重，但落地之后能省掉大量隐患。有些公司觉得“我们还没收到过通知，不用搞”，等到真收到律师函的那一天，流程排不下、代码查不清，那才是真正的麻烦。

3.3 用工具做依赖扫描，别凭感觉

手动维护组件台账可以，但依赖多了之后完全靠人盯不现实。我建议至少引入一个软件成分分析（SCA）工具做自动化扫描。

我现在在项目里比较常用的组合是 Syft 加 Grype。Syft 负责把容器镜像、目录、SBOM 里的组件信息提取出来，Grype 负责针对漏洞库做匹配。两个工具都是开源命令行工具，适合在 CI 里跑。举个简单的用法：

# 编译项目后，生成当前目录下所有依赖的 SBOM syft dir:. -o cyclonedx-json > bom.json # 对生成的结果做漏洞扫描 grype bom.json # 只输出固定格式，方便人工判断 grype bom.json --only-fixed --scope all

如果项目是 JavaScript 写的，也可以用 npm 自带的工具快速检查许可证合规性：

npm install -g license-checker # 列出当前项目所有依赖的许可证 license-checker --json --out licenses.json # 只输出违反指定白名单的组件 license-checker --onlyAllow "MIT;Apache-2.0;ISC;BSD-3-Clause"

跑完这些扫描后，你会发现“合规”这件事从模糊的感觉，变成了清晰的清单：哪些组件在用的许可证有风险，哪些版本有已知漏洞，一目了然。整个过程不需要很深的法务功底，但需要你具备“把代码当供应链来管理”的意识。

4. 常见问题与排查技巧实录

4.1 项目没有 LICENSE，算开源吗

严格来说，不算。没有 LICENSE 的代码仓库，默认就是“保留所有权利”，别人只能看，不能合法地使用、复制、修改或分发。这和“开源”的字面意思完全相反。

我见过很多开发者辛辛苦苦写了个工具，传到 GitHub，却迟迟不选许可证。问他们为什么，有人说“选 MIT 显得太随意”，有人说“我还没想好要不要商用授权”。这种情况下，项目很难获得真正的社区贡献，因为每一个潜在贡献者都会犹豫：我提的 PR 进去之后，代码算谁的？授权给谁？

所以我的建议是：项目上线前就把许可证选好。实在拿不准，先选一个宽松的，比如 MIT 或 MulanPSL-2.0。许可证是可以后续更换的，但前提是你要获得所有已有贡献者的同意，这个操作成本高得多。

4.2 GPL 的“传染性”到底怎么理解，会不会把我的商业代码也拖下水

这是企业问得最多的问题，也是最容易出误判的地方。GPL 的传染性不在于“代码接触过就会传染”，而在于“衍生作品”的定义。如果你把 GPL 代码复制、修改后，作为一个整体对外分发，那这个整体通常会被认定为衍生作品，必须采用 GPL 授权。

但如果你是通过独立进程调用、网络服务交互、或者动态链接且在运行时不合并到同一个程序里，情况就会复杂很多。不同法律体系下判断不一，实践里也没有统一答案。所以这里直接给一个可执行的建议：如果你的项目要商用闭源，默认不要引入 GPL 组件，尤其是强 copyleft 的。实在绕不开，就让法务介入评估，不要自己拍脑袋说“我们只是用了它一个算法而已”。

同理，LGPL 允许动态链接，但如果你修改了 LGPL 库本身的代码，那部分修改仍然要开源。MPL 是文件级传染，比 GPL 温和一些。理解这些颗粒度差异，比背条文有用得多。

4.3 企业收到合规审计通知怎么办

有些企业是被上游提醒“你们在用我们的组件，但你们没有遵守许可证条款”，这时候切忌慌乱删除代码。正确做法是：

1. 先固化证据：把当前使用的组件版本、构建产物、SBOM 全部备份。
2. 全面自查：立即扫描所有依赖，确认传播范围和涉及组件。
3. 评估影响：根据许可证条款，判断是缺声明、缺源码提供，还是有更严重的属性变更。
4. 准备修复方案：补一份 NOTICE 或 license header，必要时在限定时间内公开源码或停止分发。
5. 与权利人沟通：主动说明情况，说明修复计划，绝大部分开源维护者要的是“合规”，不是把你告上法庭。

从我的经验看，很多审计事件最后都止步于“补一个声明文件”。但如果在收到通知后假装没事、继续分发，问题就会升级。

4.4 几个踩过的真实小坑

这里记录几个我实际踩过、也见过别人踩的坑，希望你能绕开：

这些坑在书本上可能只是一行字，但在实际合作和审计里，每一个都能让项目卡壳好几天。

5. 木兰开放日议程里，最值得关注的内容和我的参会建议

5.1 哪些议题值得重点听

虽然完整议程以官方发布为准，但从《开源法律、政策与实践》这本书的内容和当前行业热点来看，有几个方向一定会被重点拿出来聊：

• 开源许可证冲突的判例与实践：尤其是 GPL 传染性的商业判例、欧盟和美国的司法差异；
• 企业开源办公室（OSPO）的搭建经验：从零到一怎么搭、谁来做、预算怎么算；
• 开源供应链安全与合规：SBOM、软件物料清单如何在真实项目里落地；
• 国内开源政策与国际化：中文语境下的合规条款与海外项目如何衔接。

个人建议如果你是开发者而不是法务，优先听案例拆解和圆桌讨论。因为法律条文在不同场景下的解释弹性很大，听资深从业者怎么分析具体案例，比听概念解读有用得多。如果你是企业合规负责人，每一场都值得听，毕竟这种能把法律、政策、实践三张皮一次性缝合的场合不多。

5.2 参加共读活动前，新手可以做什么准备

共读会不是上课，不需要交作业，但提前做一点准备能让你的参与感翻倍。我的建议是：

• 先把目录读一遍，选出和你当前工作相关的章节，比如你正在做开源选型，就重点看许可证章节；
• 给自己准备 2-3 个具体问题，比如“我们公司用了某个 Apache-2.0 组件，但对方要求我们也开源，这合理吗”；
• 把你项目里的 LICENSE 和 NOTICE 文件找出来，看看现在缺什么，现场可以直接向专家请教；
• 下载一个 SCA 工具，把自己手头项目扫描一遍，带着扫描结果去问问题，效率极高。

如果是线上参与，也要提前测试好设备和网络。现场提问的机会很宝贵，别把时间浪费在调试环境上。

5.3 从共读延伸到落地，后续还能怎么做

一场活动和一个共读计划能解决的是“意识”和“认知”，但真正的变化发生在活动结束后。我的建议是，参加完木兰技术开放日之后，回到自己的项目或公司里，至少推动三件事：

• 给现有项目补全许可证文件，把开源合规四件套配齐；
• 把依赖扫描接入 CI 流程，不是扫一次就结束，而是每次提交都扫；
• 建立一份内部的“开源使用规范”，不用很复杂，一张纸就行，但要写清楚什么能引入、什么要审批。

开源的法律和政策，本质上是在回答一个问题：我们如何建立信任。你把代码交出去，别人才能基于它做下一步创新；你把规则定清楚，社区才能持续协作。所有工具、扫描、证书，都只是在维系这份信任。

说实话，我这些年被各种许可证问题折腾过太多次，从最开始的“完全没概念”，到现在能写清楚一份 NOTICE 文件，靠的都是一次次踩坑和补课。现在有一套系统性的书和活动把这条路铺平了，真的很推荐你参与进去。哪怕只是带上项目清单去听一场圆桌，你的收获都会比想象中大。