企业官网建设流程全解析

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 给企业技术管理者：搭建开源合规基线

对于企业场景，我的建议是不要试图在每一个项目上做“完整法律审查”，那会耗尽工程团队的耐心。更务实的路径是建立一套基于风险分级的开源合规基线：

这个分级逻辑背后是对法律风险的实际理解：很多许可证义务（比如 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% 的日常困惑

书读得再多，遇到自己项目里的具体问题还是会懵。这里我把这几年在社区和企业里被问得最多的几个问题集中做个解答，算是把共读内容向实操层面再延伸一步。

这些问题的结论不能覆盖所有场景，每个具体项目还是要单独做判断。但这张表能帮大多数团队避开最常见的认知误区。

再补充一个容易忽略的细节：修改了开源代码之后，很多项目的做法是只保留 LICENSE 文件，但删掉了所有关于上游作者的信息。这在 MIT 和 Apache 许可证下是不合规的。许可证要求你保留的是“完整的版权声明集合”，光有 LICENSE 文件不够，源文件头部那些 copyright 注释同样是声明的一部分。我见过不少公司因为删得太“干净”，最后被原作者找上门要求下架整改的。

6. 复盘 COSCon‘25 木兰技术开放日的议程亮点

聊完书和实操，再回头看这份刚发布的议程。木兰技术开放日把“法律、政策与实践”做成共读专题，不是临时起意的策划，而是这几年国内开源生态发展的必然产物。

议程里如果只选一个我最关注的环节，是那些结合具体案例讨论许可证冲突和合规实践的部分。因为国内做开源治理的团队越来越多，但成熟方法论很少，大部分团队卡在同一个地方：知道要合规，不知道从哪一步开始。这种基于真实项目复盘的内容，远比空谈“技术无罪”有价值。

另外，议程中“实践”这一词的出现频率很高，这个导向我是认可的。开源法务不是一个纯法律议题，它最终要落到代码仓、CI 流程、发布产物这些工程事实上。所以真正有效的共读，应该是带着自己项目的 SBOM 来读、带着自己遇到过的合规问题来读，而不是听完一场报告就散场。

COSCon‘25 的这次木兰技术开放日，如果能在现场带大家建立一个共识——开源是一条权利和义务并存的协作模式，那么它对整个中文开源社区的价值，会远远超过一场活动本身。

7. 写在最后的一点个人建议

参与开源法务相关讨论这几年，我最大的感受是：大多数开源合规问题都不是恶意违规，而是“不知道”。不知道改了什么协议、不知道依赖里有 GPL 组件、不知道保留版权声明是义务而不是情分。所以共读这本《开源法律、政策与实践》最重要的意义，其实是把“不知道”变成“知道”。

作为从业者，我建议参加这次共读的人提前做两件事：第一，给自己在维护的开源项目生成一份 SBOM，带着它去现场对照书里的合规流程；第二，把你最近遇到的一个“许可证困惑”记下来，在互动环节直接问。这种有备而来的共读，收获会完全不一样。开源世界里，会写代码是能力，知道代码怎么授权、怎么合规流动，是另一种更稀缺的能力。愿你早点拥有。