开源合规实战：从许可证到SBOM的自查指南

COSCon‘25 的议程刚刚发布，最让我眼前一亮的是木兰技术开放日这一场——主题直接“共读《开源法律、政策与实践》”。我在开源圈混了十来年，见过太多因为许可证没整明白而翻车的项目，也帮不少公司处理过依赖合规的烂摊子，所以看到这个议程的第一反应是：这门课早该补上了。这篇不是官方的议程解读，而是我作为开发者、维护者和合规咨询者，结合这份议程聊聊开源法律与政策到底在讲什么，以及你该怎么从一场论坛或一本书里，真正把这些规则变成手上的工具。无论你是写代码的、管项目的，还是给公司把关法务的，都值得往下看。

1. 开源不是“免费拿”，法律合规正在成为硬门槛

1.1 许可证不是摆设，它是代码流通的合同

“开源”这个词被用烂了，但很多人对开源的理解停留在“代码不要钱”。开源协议本质上是一份著作权许可合同，作者保留著作权，通过许可证把复制、修改、分发、使用的权利授给你，同时给你附加条件。你接受代码的那一刻，就等于接受合同条款。比如MIT、Apache 2.0、BSD这类宽松协议，条件少，保留版权声明即可；GPL、LGPL、AGPL这类Copyleft协议，条件多，涉及分发或网络服务时，可能需要开源衍生代码。这不是道德要求，是法律义务，真到了争议解决环节，合同是不会跟你讲“我以为”的。

我们做项目时经常遇到的第一个坑，就是把“开源”和“无主”划等号。实际上开源代码的每一行都带有作者署名和协议声明，哪怕你在GitHub上fork了一份，只要原项目写着MIT，你就要保留原始版权信息。我遇到过有人直接把项目里所有LICENSE文件删掉，美其名曰“清理干净”，结果上线前被审计出来，整条产品线差点延期。这种事平时没事则已，一旦遇到对方法务较真，轻则道歉，重则赔偿。

1.2 内部使用和对外分发的边界，决定义务差异

很多开发者有个误解：我只要不卖钱，就不是商用。其实“商用”与否并不是许可证义务的关键，关键是你是否“分发”或“通过网络提供服务”，以及你的项目是否与Copyleft代码形成“衍生作品”。比如你在公司内部用了一个GPL组件写内部工具，不给外部客户分发，通常问题不大；但如果你把编译后的程序发给客户，或者放在云上让客户通过网络访问，那就可能触发分发义务。AGPL更是把“通过网络提供服务”也纳入了开源义务的范畴。

我见过最典型的翻车场景，是一家做SaaS的创业公司，把某个AGPL组件嵌在后台服务里，创始人觉得“后台代码又没人看见”，结果竞争对手发来律师函，业务被迫暂停两个月整改。这个教训其实在开源圈反复讲，但还是有人踩。所以每次做技术选型的时候，我都会带着依赖清单和协议表格去评审，不是扫兴，是保命。

1.3 木兰协议族：中文开源世界自己的规则

木兰技术开放日之所以值得关注，核心是“木兰”这两个字背后有一整套国产开源协议体系。木兰宽松许可证（MulanPSL）是国内发起的开源许可证，MulanPSL v1.0是较早由我国主导并接受国际社区关注的开源许可证，v2.0则在法律条款和表达上更成熟。它的特点是用中文就能看懂，比很多英文许可证的门槛低，条款上尽量与Apache 2.0对齐，同时补了一些面向国内法律环境的细节。对国内项目来说，用木兰协议可以减少理解偏差；对接收国外项目的企业，也多了一个更清晰的选择。

当然，国内还有一些其他协议和合规工具，但木兰社区这几年一直在做普及工作，包括提供许可证文本、FAQ、兼容性指南，以及这次COSCon上的议题设计。从实际选择来看，如果你维护的项目希望既宽松又容易理解，木兰宽松许可证是比较稳妥的起步选项。我自己的一个社区项目，也把许可证从MIT换成了MulanPSL v2，不是跟风，而是想让不懂英文的协作者也清楚自己拥有的权利。

2. COSCon‘25 木兰技术开放日议程怎么看

2.1 “共读”这个动作，比单纯演讲聪明在哪

这次议程里“共读”两个字特别醒目。法律文本本身就是晦涩的，你在台上讲一个小时，下面能记住30%就不错了。“共读”把姿态放低，让参与者围着一本书、几篇条款逐段聊，有主持人的引导，也有参与者的提问，这种生成式学习的效果远超单向灌输。我觉得这特别适合开源法律这样的主题——正因为大家背景不同，有人懂代码，有人懂法条，共读才能碰撞出真实场景，而不是纸上谈兵。

我自己组织过几次内部合规学习，一开始就是拉个群发资料，结果没人看。后来改成每周一次“共读半小时”，轮流找案例，带着问题读条款，效果完全不一样。所以看到COSCon把共读搬进议程，我觉得主办方是真的摸到了开源合规教育的命门。

2.2 法律、政策、实践三个模块分别解决什么问题

从标题拆开看，“法律”是底线，讲许可证、著作权、专利与商标。比如你写的代码用了别人的算法，是否涉及专利，你的项目名称是否侵了别人的商标。“政策”更多是围绕开源社区和企业的规则设计，比如贡献者协议、行为准则、发布流程、开源办公室的职责，这些不是法律强制，但一旦写在章程里，就有约束力；“实践”则是把这些规则落到代码仓库、CI流水线、产品发布清单里。三者环环相扣，缺一不可。

具体到议程可能涉及的内容，我推测至少会覆盖许可证兼容性案例分析、企业开源项目治理、以及合规工具链的落地。尤其是“共读《开源法律、政策与实践》”这个环节，大概率会把某几个高频案例拿出来讨论，比如GPL依赖处理、云服务场景的AGPL义务、社区贡献者遇到纠纷怎么办。这些都正中靶心。

2.3 谁适合来听，能带走什么

如果你是开源项目的维护者，你能带走一套判断许可证兼容性的思维框架；如果你是企业的技术负责人或法务，你能带走合适的开源治理机制，比如怎么建开源办公室、怎么管理依赖清单；如果是刚接触开源的新人，你能建立最基本的底线意识，避免从第一个PR开始就踩法律坑。坦白讲，开源的准入门槛越来越低，法律意识的门槛却被很多人忽略。这样的开放日提供的不是冷冰冰的法条，而是跟你工作直接挂钩的实践方案。

我建议报名的时候不要只自己来，最好带上研发、法务、产品各一个人。一个健康的开源项目或商业产品，从来不是技术一个部门能撑起来的。现场哪怕只记住一两个检查点，回去推动落地，价值都比听十个泛泛而谈的分享大得多。

3. 从议程到落地：一份开源合规自查实操指南

3.1 第一件事：把家底摸清楚，生成SBOM和依赖清单

看再多论坛，不如自己动手跑一遍合规。第一步就是盘点。SBOM（软件物料清单）是现在业界常用的基础设施，可以把它理解成“你做的这锅饭用了哪些食材、各自产自哪里、保质期多长”。你需要把你项目的所有直接依赖、传递依赖、构建工具、容器镜像里的系统包全部列出来。现在很多工具能自动生成SBOM，比如Syft可以把容器或文件系统扫一遍输出SPDX格式清单，Trivy除了漏洞扫描也能输出依赖信息。别觉得这是多余动作，我见过不少公司，问研发“你项目里有哪些开源依赖”，得到的回答都是“大概有十几个吧”，一扫描出来一百多个。

生成SBOM之后，最好把它纳入仓库版本管理，每次发版或者依赖升级时重新生成一份。这份清单本身不是合规，但它是后面所有判断的基础。没有清单，就像一个人不知道自己吃了什么过敏，等到出事再去查，代价就大了。

3.2 第二件事：逐项核对许可证，补版权声明

有了清单，接下来就是逐项核对。这一步要细，不能靠印象。每个组件都要回答四个问题：许可证是哪一种？版权所有者是谁？我是否做了修改？我的使用方式是内部、分发还是网络服务？然后对照许可证条款看看要履行哪些义务，最常见的是保留版权声明、复制LICENSE文件、在NOTICE里注明来源。Apache 2.0还要求如果修改了文件，需要标记变更，很多项目在这点上习惯性忽略。

你可以用SPDX许可证清单来比对，用Licensee、ScanCode这类工具半自动识别代码库里的许可证文本。但要注意，自动识别只能帮你定位，真正的法律判断还是要人来下。遇到拿不准的情况，保守做法是保留所有声明，同时把你改过的部分单独说明，避免把多个来源的代码混在一个文件里。我见过有人把MIT的有效信息原封不动保留，但把Apache 2.0的NOTICE文件给漏了，最后审计被打回。细节就是地狱，合规这活儿没有捷径。

3.3 第三件事：把合规检查嵌进自动化流程

手工检查总会漏，最靠谱的办法是把合规检查做成自动化的一部分。在CI流水线里加一个许可证检查步骤，比如用license-checker这类工具，或者接入商业级的合规平台，在每次提交或发版时自动跑一遍，一旦发现新依赖的许可证类型与项目策略冲突就直接报错。策略怎么定？比如你的产品是闭源商业软件，你可以规定允许MIT、BSD、Apache 2.0这类宽松许可证，禁止新增GPL/AGPL依赖，除非经过法务特批。这样把“能不能用”的判断从个人经验变成组织规则。

自动化的价值不只是省人力，更重要的是它把合规动作前置到了“代码进入仓库之前”。等交付前再审计，返工成本极高；改一行依赖可能牵一发动全身。我从做合规咨询开始就反复强调一句话：没有流程，就只能靠运气，而运气通常都不站在不设防的人这边。

4. 社区治理与开源政策：贡献者协议和项目章程

4.1 CLA还是DCO，项目维护者该怎么选

如果你维护一个开源项目，只要有人提交PR，你就开始碰“贡献者协议”这个敏感区。CLA（Contributor License Agreement）是贡献者将代码使用、修改、分发等权利授予项目方的正式协议，通常需要签名，适合公司主导、计划商业化的大项目；DCO（Developer Certificate of Origin）则轻得多，通过git commit -s签名，表示你确认代码是你写的或有权提交，Linux内核采用这种模式。很多国内项目对CLA不陌生，但真正落地时往往因为流程繁琐劝退贡献者。

我的建议是：社区型项目优先用DCO，公司型产品化项目可以上简化版CLA。木兰社区也提供了一些参考模板，可以把中文条款与开源许可证衔接好。最怕的是项目没有明确的贡献者协议，所有人默认以“GitHub条款”为依据——万一哪天项目商业化，或者某位核心贡献者离职后追责，你连授权链都说不清。

4.2 项目章程和行为准则也是“政策”

很多人一听到“政策”就想到大词，但在开源语境里，项目自己的CONTRIBUTING文件、CODE_OF_CONDUCT、版本命名规范、商标授权政策，都是实实在在的项目政策。它们决定了这个项目怎么运转、怎么讨论、怎么处理冲突。一个没有行为准则的项目，很容易在争议中失控；一个没有商标政策的开源项目，也会在生态繁荣后被各种“非官方”版本搞坏口碑。

所以我在参与社区治理时，会建议团队把政策文档当成代码一样维护：写明版本，写清适用范围，放README和官网都行但必须显眼。这也是“共读”活动对我最大的启发——政策不是挂在墙上的，而是要在行动里反复阅读、解释、修订的。

4.3 企业内部怎么组织“共读小组”落地学习

每一次讨论都容易停留在“我们知道要合规”，真正改变行为很难。我在公司组织共读小组时，第一步是拉人，范围一定要跨部门：研发、法务、产品、运营，甚至采购，因为开源合规可能涉及第三方采购合同。第二步是选书，像《开源法律、政策与实践》这种书比较适合全面了解框架，但光读肯定不够，每章配一个真实案例讨论。第三步是产出，共读不是读书会，要求每期结束输出一份可执行检查清单或决策记录，比如“本月识别出3个不合规依赖并已替换”。

这个习惯保持半年之后，团队的合规意识会有质的提升。我已经实践了不止一次，效果非常直观：新项目在技术选型的阶段就会主动带许可证清单，因为大家知道，后面改比前面做麻烦太多了。

5. 开源合规常见问题与排查技巧

5.1 只在内部用，是不是啥都不用管

这是被问得最多的一个问题。答案要先分清楚使用方式：代码不传到公司外部，一般不会触发“分发”义务。但这不等于完全没风险，有两个例外很关键：一是如果你的服务允许外部用户通过网络访问，而依赖中包含AGPL组件，就可能需要开源整个服务的对应源码；二是如果公司在内部开发中修改了Copyleft代码，并将其整合进商业产品（即使产品还没卖），一旦未来分发，传染链条已经形成。所以“内部用”不是免责金牌，只是延后义务，潜在负债不能当不存在。

5.2 依赖了GPL组件，还有救吗

“GPL污染”听起来吓人，但不是必死局。先分场景：如果你只是把GPL组件作为独立的命令行工具调用，进程隔离，通常不视为衍生作品；如果你是动态链接库，争议就大；如果直接把代码抄进自己的源码，那基本逃不掉。面对已有存量，正确姿势是：先定位感染面，能换就换，不能换就考虑隔离成独立进程并通过接口交互，或者找权利人去谈商业授权，再不行走法务评估。我见过不少项目通过重写关键模块从GPL里逃出来的，代价不小，但至少比律师函砸下来再动手好太多。

5.3 用木兰许可证就万事大吉了吗

木兰宽松许可证解决了一部分国内选择困难，但它不是万能锁。反过来，用了木兰许可证，依然要遵守它的条款，比如保留版权声明、不得使用商标暗示背书。另外，许可证兼容不是看名字长得像就行，要看具体条款。MulanPSL v2与Apache 2.0在很多商业使用场景下兼容性较好，但如果你依赖了GPL系组件，还是要按Copyleft规则处理。我见过有人以为“都是国产协议，应该都一样”，结果把木兰协议代码和另一个协议代码混在一起，又没标注变更记录，最后评审时被揪出来。规则永远不嫌多，关键是把每一条都落到文档里。

5.4 一份可以直接抄的快速自查清单

下面的表格是我在项目发布前常用的一份自查清单，不能覆盖所有场景，但足够拦住大部分的低级问题。建议贴在团队成员都能看到的地方。

这张表不是让你机械打勾，而是逼你面对最不愿意面对的角落。我几乎每次做合规审查，都能在“版权声明”和“传递依赖”两栏找到问题，这两块靠人脑是真不可靠。

最后再分享一个小技巧。如果你所在团队还没有任何合规积累，别一上来就追求大而全的制度。先从这张表开始，挑一个正在进行的项目做试点，跑通一遍流程，把发现的问题记录下来。干完一个项目，你就可以把这份清单“演进”成你团队自己的合规手册。开源法律和政策的门道确实很多，但入门就靠一条原则：把每一段别人写的代码都当成一份合同，读懂了再签字。我阅了很多项目，判断一个人是不是真把开源当回事，最简单的办法就是问他“你项目里那个开源组件是什么许可证”，如果他能不看搜索引擎直接说出答案，那就说明他和这份法律文本之间，已经建立了真正的信任。这个习惯，我建议你从下一次依赖升级开始养成。