最近后台隔三差五就有人来问我“我项目明明写了 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宽松保留版权和许可声明高jQuery、Node.js 早期Apache-2.0宽松保留声明、标注修改、提供 NOTICE高Kubernetes、HadoopBSD-3-Clause宽松保留声明、禁止用作者名义做背书高Redis 旧版、Nginx 部分GPL-3.0强 copyleft衍生产品必须同样 GPL 授权低Linux、GitLGPL-3.0弱 copyleft动态链接可不传染修改库本身需开源中FFmpeg 部分组件MPL-2.0弱 copyleft文件级开源可与其他授权混合中Firefox选许可证最怕的就是“跟风”。个人项目图省事可以选 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 企业做开源合规的流程企业用户踩的坑和个人完全不是一个量级。个人顶多是被要求删除代码企业一旦违规面临的可能是商业谈判中的筹码损失甚至诉讼。一套基本的企业开源合规流程大致是这样建立开源组件台账引入任何开源组件之前先登记记录组件名、版本、许可证、URL。依赖来源审查确认组件来自官方仓库或可信镜像避免引入恶意篡改版本。许可证扫描与冲突检测用工具自动识别依赖树中的许可证检查是否存在 GPL 传染、许可证互斥。合规评估与例外申请如果检测到高风险许可证提交给合规委员会评估必要时走例外审批流程。对外发布前的审计对外发布 SDK、应用或容器镜像之前做一次全量扫描。定期复扫依赖一升级就可能导致新增许可证需要周期性重新扫描。这套流程听起来重但落地之后能省掉大量隐患。有些公司觉得“我们还没收到过通知不用搞”等到真收到律师函的那一天流程排不下、代码查不清那才是真正的麻烦。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 企业收到合规审计通知怎么办有些企业是被上游提醒“你们在用我们的组件但你们没有遵守许可证条款”这时候切忌慌乱删除代码。正确做法是先固化证据把当前使用的组件版本、构建产物、SBOM 全部备份。全面自查立即扫描所有依赖确认传播范围和涉及组件。评估影响根据许可证条款判断是缺声明、缺源码提供还是有更严重的属性变更。准备修复方案补一份 NOTICE 或 license header必要时在限定时间内公开源码或停止分发。与权利人沟通主动说明情况说明修复计划绝大部分开源维护者要的是“合规”不是把你告上法庭。从我的经验看很多审计事件最后都止步于“补一个声明文件”。但如果在收到通知后假装没事、继续分发问题就会升级。4.4 几个踩过的真实小坑这里记录几个我实际踩过、也见过别人踩的坑希望你能绕开场景问题表现解决办法使用了 Apache-2.0 组件但没提供 NOTICE法务审计不过必须逐版本补声明用 SCA 工具生成依赖清单批量补 NOTICE 模板仓库里有 GPL 代码却整体标了 MIT误导使用者实际存在授权冲突单独拆出 GPL 文件目录README 里标明例外从博客复制了一段“无版权声明”的代码作者未声明不代表放弃版权商用风险较高联系作者确认授权或重写替代实现给开源项目提 PR 却忽略 DCO 签署大项目会拒绝合入要求强制签名提交前看 CONTRIBUTING跑git commit -s镜像站同步了上游代码但没修改 logo潜在商标风险商标和版权是两套体系只保留上游授权的素材不擅自使用商标这些坑在书本上可能只是一行字但在实际合作和审计里每一个都能让项目卡壳好几天。5. 木兰开放日议程里最值得关注的内容和我的参会建议5.1 哪些议题值得重点听虽然完整议程以官方发布为准但从《开源法律、政策与实践》这本书的内容和当前行业热点来看有几个方向一定会被重点拿出来聊开源许可证冲突的判例与实践尤其是 GPL 传染性的商业判例、欧盟和美国的司法差异企业开源办公室OSPO的搭建经验从零到一怎么搭、谁来做、预算怎么算开源供应链安全与合规SBOM、软件物料清单如何在真实项目里落地国内开源政策与国际化中文语境下的合规条款与海外项目如何衔接。个人建议如果你是开发者而不是法务优先听案例拆解和圆桌讨论。因为法律条文在不同场景下的解释弹性很大听资深从业者怎么分析具体案例比听概念解读有用得多。如果你是企业合规负责人每一场都值得听毕竟这种能把法律、政策、实践三张皮一次性缝合的场合不多。5.2 参加共读活动前新手可以做什么准备共读会不是上课不需要交作业但提前做一点准备能让你的参与感翻倍。我的建议是先把目录读一遍选出和你当前工作相关的章节比如你正在做开源选型就重点看许可证章节给自己准备 2-3 个具体问题比如“我们公司用了某个 Apache-2.0 组件但对方要求我们也开源这合理吗”把你项目里的 LICENSE 和 NOTICE 文件找出来看看现在缺什么现场可以直接向专家请教下载一个 SCA 工具把自己手头项目扫描一遍带着扫描结果去问问题效率极高。如果是线上参与也要提前测试好设备和网络。现场提问的机会很宝贵别把时间浪费在调试环境上。5.3 从共读延伸到落地后续还能怎么做一场活动和一个共读计划能解决的是“意识”和“认知”但真正的变化发生在活动结束后。我的建议是参加完木兰技术开放日之后回到自己的项目或公司里至少推动三件事给现有项目补全许可证文件把开源合规四件套配齐把依赖扫描接入 CI 流程不是扫一次就结束而是每次提交都扫建立一份内部的“开源使用规范”不用很复杂一张纸就行但要写清楚什么能引入、什么要审批。开源的法律和政策本质上是在回答一个问题我们如何建立信任。你把代码交出去别人才能基于它做下一步创新你把规则定清楚社区才能持续协作。所有工具、扫描、证书都只是在维系这份信任。说实话我这些年被各种许可证问题折腾过太多次从最开始的“完全没概念”到现在能写清楚一份 NOTICE 文件靠的都是一次次踩坑和补课。现在有一套系统性的书和活动把这条路铺平了真的很推荐你参与进去。哪怕只是带上项目清单去听一场圆桌你的收获都会比想象中大。