COSCon‘25 的技术议程最近放出来了其中“木兰技术开放日”那一栏有个环节特别扎眼——《开源法律、政策与实践》共读。懂行的一看就知道这书不是随便拿来翻翻的那种它把开源从“代码怎么写”拉到了“开源怎么治理”这个层面。今天就借着这份议程把开源法律合规这条线从头捋一遍聊聊为什么2025年的开源圈绕不开一本讲“法律和政策”的书以及那些真正在搞开源项目、做企业开源治理的人能从这次共读里挖到什么实际有用的东西。1. 先聊清楚为什么开源技术大会要专门设一个“法务向”开放日很多人一听到“开源法律”四个字就觉得离自己很远觉得那是公司法务和国外律师才需要关心的东西。但实际上只要你的项目放在 GitHub 上、用了别人的开源组件、或者公司内部有基于开源软件的商业化产品你就已经站在开源法律和政策的辐射范围里了。只是很多人暂时还没踩到坑而已。1.1 开源许可证不是“声明”而是“合同”很多人对开源许可证的理解停留在“这代码能免费抄”的层面。这是最大的误区。许可证本质上是版权人写的一份授权合同它回答的问题只有一个别人用你的代码时可以做什么、不可以做什么。MIT、Apache-2.0 看着宽松但它照样有条款GPL 系列看着严格但严格并不等于“不可商用”。真正的区别在于你拿到代码之后对修改版本和衍生作品有没有开放源码的义务。举个例子很多人以为“MIT 协议就是随便用”这个说法省了一个重要前提MIT 要求保留原版权声明和许可证文本。你把别人 MIT 的代码复制到自己项目里然后把作者信息删了这在法律上是不合规的哪怕 MIT 再宽松版权署名权也不是能随便抹掉的。这就是合同条款的实际约束力。1.2 为什么要专门谈“政策和实践”只看许可证文本解决不了实际问题。因为现实世界里没有哪个项目是单一许可证铺到底的。一个成熟的软件项目往往同时混合了 Apache-2.0、MIT、BSD、LGPL、GPL 甚至 SSPL 的组件依赖树展开之后几十上百个节点。这种情况下“我的项目是什么许可证”已经很难回答更难的是“我的项目怎么在多重许可证共存的情况下合法分发”。这时候“政策”就有了意义。开源政策不是某一家公司的制度文件而是整个生态里共同形成的实践准则、审批流程、合规工具链以及像开放源代码促进会OSI这类组织对“什么是开源”的认证和倡导。把这些东西串起来才是《开源法律、政策与实践》这本书想解决的问题。1.3 为什么是木兰技术开放日来做这件事木兰这个品牌在国内开源体系里是有特殊位置的。从木兰宽松许可证到木兰公共许可证再到木兰社区的各类基础设施它一直在试图给中文世界的开源项目提供一套更贴近本土实践的规则工具。木兰宽松许可证之所以在国内受欢迎一个核心原因是它比照 Apache-2.0 做了一些精简更符合中文语境同时保留了专利授权条款。这次木兰技术开放日专门把法律和政策共读放进COSCon‘25的议程本质上是在补国内开源生态的一块短板——我们缺的不只是代码贡献者更缺懂规则、能落地合规治理的人。2. 把书拆开看《开源法律、政策与实践》到底讲了什么既然是要“共读”就得先弄明白这本书的知识骨架。很多社区的共读活动容易流于形式一人念一段、大家聊聊天就完了。但要想真读透最好还是先把章节逻辑摸清楚带着问题去读。2.1 版权法与开源许可证的基础逻辑这一块是所有后续讨论的地基。书里不会给你一本版权法教科书但会把开源领域最相关的版权法原则讲清楚比如版权保护的是表达而非思想所以“照着思路重写”和“复制代码”在法律上是两回事授权与转让的区别开源许可证是“授权”而不是“转让”原作者始终保留底层版权衍生作品的判断标准修改源码算不算衍生动态链接算不算静态链接算不算——这些问题在法律和工程实践之间长期存在灰色地带对这些基础概念有共识之后再去看 GPL、LGPL、Apache、木兰等具体许可证的条文才不会觉得是在看天书。2.2 许可证兼容性与组合分发这本书把许可证兼容性单独拿出来讲我觉得是写得最有实操价值的部分。因为不管你写不写代码只要你做软件集成、做产品打包就一定会撞上许可证相互打架的情况。举一个很常见的例子你的项目主体用的是 GPL-2.0但你想引入一个 Apache-2.0 的组件。从 Apache-2.0 向 GPL-2.0 的兼容方向来说Apache-2.0 的代码可以并入 GPL-2.0 项目因为 Apache-2.0 的条款让渡了足够的权限。但反过来如果项目主体是 Apache-2.0你就不太可能在不开源的情况下把 GPL-2.0 代码直接并进来。这类“单向兼容”关系书里梳理得比较清楚能帮人避开非常多基础性的合规错误。2.3 开源治理与组织级合规实践这是书里和中国开发者关系最密切的部分之一。因为个人开发者违规顶多是项目被投诉、被要求下架企业级违规面对的是商业诉讼、并购障碍、甚至监管风险。书中会讲成熟的开源治理体系怎么搭从开源软件引入审批、到依赖清单维护、再到发布前的许可证合规扫描最后是定期审计和员工培训。这套流程不是说给法务听的而是说给每一个参与软件交付的人听的。2.4 政策部分从国家战略到基金会规则“政策”在开源语境里有两层一层是国际开源基金会如 Apache 基金会、Linux 基金会、开放原子开源基金会等的章程和项目治理规则另一层是国家层面的产业政策导向。这本书把两层面放在一起讲能帮读者理解一个现实开源早已不只是一个技术协作模式它同时是技术创新体系里的制度基础设施。3. 从“读”到“用”共读活动背后的实操转化路径“共读”最大的价值不是读完书而是把书里的知识用自己的项目和组织的真实场景对照一遍。参加 COSCon‘25 木兰技术开放日的这次共读我在意的是这个环节能带出多少可迁移到日常工作中的经验。3.1 给个人开发者选许可证、改许可证、补声明个人开发者最容易犯的几个合规错误我觉得值得直接摆出来直接删掉上游 LICENSE 文件。很多人觉得保留 LICENSE 文件占地方或者“我改过了原作者协议不用留了”这是错的。无论你基于 MIT、Apache 还是 BSD 代码做了多大的改动上游的版权声明和许可证文本都必须原样保留在你的分发版本里。自己“发明”许可证。经常看到有人从网上复制一段 “Do What The Fuck You Want To” 之类的非标准文本或者自己写一段“仅限学习交流禁止商用”。这类表述在法律上极度不确定它可能根本不是有效的许可证也可能因表述不清导致授权范围无法推定。不推荐在正式项目里这么干。替换许可证不跟原作者打招呼。如果你打算把别人的代码从 GPL 改为 MIT 再发布这个操作本身就是违规的因为 GPL 授权下你不能单方面改授许可条款。你能做的只是在“自己的原创代码部分”使用你选择的新许可证而上游部分必须沿用原有许可证。共读活动中如果覆盖到这些场景就远比单纯念条款有用。3.2 给企业技术管理者搭建开源合规基线对于企业场景我的建议是不要试图在每一个项目上做“完整法律审查”那会耗尽工程团队的耐心。更务实的路径是建立一套基于风险分级的开源合规基线风险等级场景关键动作低风险内部工具、原型验证、非分发软件记录 SBOM 即可许可证合规压力极低中风险对外提供 SaaS 服务不分发软件重点排查传染性许可证对云服务的延伸要求高风险软件对外分发含嵌入硬件逐组件做许可证分析、检查代码来源、保留合规审计记录这个分级逻辑背后是对法律风险的实际理解很多许可证义务比如 GPL 的 copyleft只有在“分发”行为出现时才被激活。如果是纯内部使用义务范围很有限。所以合规工作不能一刀切而应对应不同的商业场景采用不同的治理深度。3.3 给社区贡献者理解 CLA 和 DCO共读里如果涉及到“给开源社区贡献代码”这一环那 CLA贡献者许可协议和 DCO开发者原创证书就是绕不开的话题。不少开发者第一次向 Apache 基金会项目提交 PR 时被要求签署 CLA第一反应是“我一个写代码的怎么还要签法律文件”。其实逻辑很简单项目要保证代码可以持续以开源许可证发布就必须确保每一个贡献者都拥有其贡献内容的知识产权并且愿意授予项目这一使用权。CLA 就是把这个过程正式化。而 DCO 则相对轻量它通过每个提交里的 Signed-off-by 信息来声明“我自己写的我有权提交”。了解这两者的区别能让你在向大型开源项目提交代码时少走很多弯路。4. 合规工具的实践笔记光读书不做扫描是远远不够的共读不能只停留在纸面。我的经验是读法律条款和做实际扫描必须同步进行否则书读完了项目里该有的许可证冲突依然一个不少。4.1 从 SBOM 开始先搞清楚自己有什么SBOM软件物料清单这个概念这两年在供应链安全语境下被反复提及但在开源合规领域它其实更基础。没有 SBOM你的依赖库存量就是一笔糊涂账。只有当你把“项目依赖了哪些组件、分别是什么版本、用了什么许可证”列清楚之后后续的许可证冲突分析才有对象。实操层面我推荐用Syft生成 SBOM再用Grype搭配做漏洞扫描。这两个工具都是开源项目使用门槛很低一条命令就能输出当前容器的依赖清单。syft packages ./myapp --format cyclonedx-json sbom.json生成的 SBOM 里会包含每个组件的 license 信息虽然有的组件 license 字段是 unknown得人工确认这就是后续分析的基础材料。4.2 用 FOSSology 和 ScanCode 做许可证扫描如果你需要扫描的不是依赖清单而是整个代码仓里所有源文件的许可证声明那需要的是FOSSology或ScanCode这类工具。它们能在文件级别做文本扫描识别出每个文件中的许可证标识、版权声明等关键信息。我自己更常用 ScanCode因为它的报告格式更友好输出 JSON、HTML、SPDX 等多种格式。SPDX 格式尤其值得用它是国际上通行的许可证数据交换标准方便你把扫描结果直接对接审计工具和合规管理平台。scancode --license --copyright --spdx-tv out.spdx .跑完这个命令你会得到一个文件级别的许可证清单。别指望扫描结果100%准确工具只能做文本模式匹配一些变体写法、拼接式许可证文本还是需要人工判断。但工具有一个巨大好处它能把需要人工关注的量压缩到可处理范围。4.3 许可证冲突判断的“最小操作集”拿到 SBOM 和扫描结果后怎么快速判断有没有大的合规风险我给自己定了一套“最小操作集”先看有没有 GPL-3.0 / AGPL-3.0 的组件如果你的项目是闭源商业分发这些组件往往是最大的风险敞口再看 GPL-2.0 和 Apache-2.0 的混合情况虽然 Apache-2.0 代码可以进入 GPL-2.0 项目但反过来风险很大确认 JavaScript/前端依赖里有没有 “BUSL” 或 “SSPL” 的组件这些非 OSI 认证许可证在云服务场景下有特殊限制比如 Redis 之前的主从模式变更用的就是 SSPL 的思路对所有未知许可证的组件打上人工确认标记不要默认它没问题这套操作不需要你成为法律专家但它能保证你在交付前不会犯最基础的合规错误。5. 几个高频开源法务问题能解决 90% 的日常困惑书读得再多遇到自己项目里的具体问题还是会懵。这里我把这几年在社区和企业里被问得最多的几个问题集中做个解答算是把共读内容向实操层面再延伸一步。问题结论说明我用了 GPL 组件做内部工具需要开源吗不需要只要不对外分发GPL 的 copyleft 义务通常不会被触发我把 MIT 项目的代码改了发布时需要开源我的修改吗不需要MIT 不要求修改部分开源只需保留版权声明用木兰宽松许可证的代码能和 Apache-2.0 混用吗可以两者兼容性良好都允许后续采用不同许可证分发公司买了商业软件里的开源组件合规责任能转移吗不能完全转移最终分发者仍需要对组件许可证义务负责合同条款只能分担追偿风险我用开源代码开发 SaaS 服务会被传染要求开源吗视许可证而定AGPL 明确适用于网络服务GPL 在传统解读下可能不适用但存在争议这些问题的结论不能覆盖所有场景每个具体项目还是要单独做判断。但这张表能帮大多数团队避开最常见的认知误区。再补充一个容易忽略的细节修改了开源代码之后很多项目的做法是只保留 LICENSE 文件但删掉了所有关于上游作者的信息。这在 MIT 和 Apache 许可证下是不合规的。许可证要求你保留的是“完整的版权声明集合”光有 LICENSE 文件不够源文件头部那些 copyright 注释同样是声明的一部分。我见过不少公司因为删得太“干净”最后被原作者找上门要求下架整改的。6. 复盘 COSCon‘25 木兰技术开放日的议程亮点聊完书和实操再回头看这份刚发布的议程。木兰技术开放日把“法律、政策与实践”做成共读专题不是临时起意的策划而是这几年国内开源生态发展的必然产物。议程里如果只选一个我最关注的环节是那些结合具体案例讨论许可证冲突和合规实践的部分。因为国内做开源治理的团队越来越多但成熟方法论很少大部分团队卡在同一个地方知道要合规不知道从哪一步开始。这种基于真实项目复盘的内容远比空谈“技术无罪”有价值。另外议程中“实践”这一词的出现频率很高这个导向我是认可的。开源法务不是一个纯法律议题它最终要落到代码仓、CI 流程、发布产物这些工程事实上。所以真正有效的共读应该是带着自己项目的 SBOM 来读、带着自己遇到过的合规问题来读而不是听完一场报告就散场。COSCon‘25 的这次木兰技术开放日如果能在现场带大家建立一个共识——开源是一条权利和义务并存的协作模式那么它对整个中文开源社区的价值会远远超过一场活动本身。7. 写在最后的一点个人建议参与开源法务相关讨论这几年我最大的感受是大多数开源合规问题都不是恶意违规而是“不知道”。不知道改了什么协议、不知道依赖里有 GPL 组件、不知道保留版权声明是义务而不是情分。所以共读这本《开源法律、政策与实践》最重要的意义其实是把“不知道”变成“知道”。作为从业者我建议参加这次共读的人提前做两件事第一给自己在维护的开源项目生成一份 SBOM带着它去现场对照书里的合规流程第二把你最近遇到的一个“许可证困惑”记下来在互动环节直接问。这种有备而来的共读收获会完全不一样。开源世界里会写代码是能力知道代码怎么授权、怎么合规流动是另一种更稀缺的能力。愿你早点拥有。
