企业软件项目中的开源许可证与代码所有权：在为时已晚之前需要检查什么

几乎每一个现代企业应用都建立在开源组件之上。Web 框架、界面库、数据库、构建工具，甚至 PDF 生成器这样的小部件，往往都来自采用开放许可证的项目。这是好事：成本下降，开发更快。但在这背后有两个法律问题，常常到了为时已晚才浮现：我们对所用组件的许可证负有什么义务？以及，供应商为我们开发的代码究竟归谁所有？

当公司想出售或引入投资人、接受尽职调查、更换供应商，或只是向客户销售软件产品时，这些问题就变得非常现实。本文用商业语言介绍开源许可证的基础知识、所有权与许可的区别、需要检查的合同条款，以及让代码在法律上保持干净的简单习惯。本文不构成法律意见；遇到重要决定，请咨询了解知识产权的法律顾问。

摘要

• 开源不等于没有规则：每个组件都有许可证，义务各不相同，从仅需署名到必须公开自己的代码
• MIT、BSD、Apache 2.0 等宽松许可证通常适用于商业产品；GPL、AGPL 等强著佐权许可证需要特别注意
• 定制代码的所有权不会自动归付款方，除非合同另有约定；项目开始前请检查知识产权条款
• 向供应商索取组件清单（软件物料清单）和许可证报告，并作为项目文档的一部分保存
• 经批准的许可证政策、自动扫描和记录署名等小习惯，可避免尽职调查时的昂贵问题

开源不等于没有规则

开源这个词常被误解为免费且可随意使用。实际上，开源代码是在某种许可证下发布的，许可证是一份在特定条件下授予特定权利的协议。您可以使用它，往往也可用于商业目的，但必须满足其条件。违反条件可能意味着失去使用权、面临法律主张，或被要求公开自己的代码。

由于现代应用包含数百甚至数千个组件，其中还包括由其他组件带入的组件（传递依赖），没有人能全部记住。因此，许可证管理必须是一种流程，而不是某个人的记忆。第三方组件的安全方面，在依赖项与软件供应链安全一文中已有介绍；许可证则是同一问题的法律侧面。

需要了解的三大许可证家族

许可证有数百种，但对商业决策而言，了解三大类及其影响就足够了。以下说明是概括性的，实际适用的始终是许可证文本。

1. 宽松许可证

例如 MIT、BSD 和 Apache 2.0。这类许可证给予广泛自由：您可以使用、修改和分发代码，包括用于闭源商业产品。主要义务通常是保留版权声明和许可证文本。Apache 2.0 还包含专利许可授权，保护使用者免受贡献者的专利主张。这一类通常对企业最简单也最安全。

2. 弱著佐权许可证

例如 LGPL 和 MPL。如果您修改了组件本身，这些修改必须以相同许可证共享，但仅把它当作库来使用的您自己的代码可以保持闭源，不过链接方式需满足一定条件。组件与应用的连接方式需要谨慎。

3. 强著佐权许可证

例如 GPL 和 AGPL。原则上，如果您把这类组件纳入所分发的产品，该产品整体必须采用相同许可证，并须提供源代码。AGPL 把这一点扩展到作为网络服务运行的软件：您服务的用户可能有权索取源代码。对销售产品或运营 SaaS 平台的公司来说，不知不觉混入的 GPL 或 AGPL 组件可能成为大问题。这并非禁止，但必须是经过审慎审查的有意决定。

在这三类之外，还有源码可用（source available）许可证，以及带有商业使用限制的许可证，它们有时看起来像开源，实际上却限制了使用方式。请阅读许可证，不要只看标签。

所有权与许可的区别

这两个概念常被混淆，是定制软件项目中纠纷的来源。

• 著作权归属：谁作为作品持有代码的权利。一般而言，代码的著作权最初属于其作者，或在雇佣关系中由员工完成时属于公司，除非另有协议
• 许可：使用代码的许可，可以在不转移所有权的情况下授予，可以是独占或非独占，并可在时间、地域或目的上受限

因此，当您付费请供应商开发应用时，代码不会自动变成您的。如果合同没有约定，供应商仍可能持有著作权，而您只获得范围不明确的使用许可。当您想自行修改应用、转到另一家供应商，或出售公司时，这就足以成为问题。这一主题与软件开发合同的要点和如何选择软件公司相关。

需要检查的合同条款

阅读或谈判开发合同时，请留意以下事项。具体措辞请咨询法律顾问。

• 权利转让：工作成果的著作权是否在全额付款后转让给您，以及从何时起
• 交付物范围：是否包含完整源代码、构建脚本、文档、设计和配置，而不仅仅是成品应用
• 供应商自有组件：供应商是否使用不予转让的内部库或自有框架，以及这些组件如何授权
• 第三方组件：供应商申报所用开源和商业组件及其许可证的义务
• 保证：供应商声明代码不侵犯他人权利，且不含违反许可证的代码
• 赔偿：若出现知识产权侵权主张，由谁承担费用
• 代码保管：把代码交付到您可控制的仓库，而不仅仅放在供应商账户里
• 持续性：当供应商停止运营或合作终止时，对代码和文档的访问权

如果供应商想把部分代码复用于其他客户，可以明确约定，例如对通用组件向供应商授予许可，并与您特有的业务逻辑清晰分离。关键是写下来，而不是想当然。

组件清单：一切许可证管理的基础

软件物料清单（SBOM）是构成应用的所有组件的清单，附有版本和许可证。企业客户、审计人员和监管机构越来越多地索要这份文件，因为它同时有两个用途：评估许可证合规性，以及在新漏洞公布时判断应用是否受影响。

您可以向供应商或内部团队索取：

• 直接依赖和传递依赖的清单及版本
• 每个组件的许可证，并对著佐权许可证和无法识别的许可证做特别标记
• 必须履行的许可证文本和署名声明
• 被修改或派生（fork）的组件记录
• 每次重大发布时更新此清单

自动扫描工具可以根据代码生成这份清单并标出冲突。把它作为自动化测试与 CI/CD流程的一部分运行，意味着在添加组件时就能发现违规，而不是多年之后。

简单但坚定的许可证政策

拥有软件产品，或经常委托定制软件的公司，应当有一份一页纸的组件许可证政策。

• 绿色清单：无需批准即可使用的许可证，通常是 MIT、BSD、Apache 2.0 及类似许可证
• 黄色清单：使用前需要审查的许可证，例如 LGPL、MPL 或带有特殊限制的许可证
• 红色清单：未经法律批准不得用于特定产品的许可证，例如用于分发或作为服务运行的产品中的 GPL 和 AGPL
• 审批流程：黄色清单由谁决定，以及决定如何记录
• 署名义务：版权声明显示在何处，例如关于页面或应用内的许可证文档

政策不必复杂。目标是让开发人员和供应商在编写代码之前就知道边界，而不是产品上市之后。

AI 时代的特殊风险

基于 AI 的编程助手的兴起带来了新的层面。模型建议的代码可能与某个开源项目的片段相似，而 AI 输出的著作权和许可状态在许多国家的法律上仍在发展中。明智的做法是为使用这类工具制定规则，在可用时启用对公开代码匹配的过滤，并像对待其他代码一样审查和扫描 AI 辅助生成的代码。更广泛的讨论见AI 辅助软件开发：机遇、风险与质量控制一文。

同样，AI 模型本身也常以特殊许可证发布，包括商业使用限制或用户数量门槛。选择模型时，要像选择库一样仔细阅读其许可证。

尽职调查时通常会问什么

投资人、潜在买家或大客户常要求提供代码干净的证明。常见问题包括：

• 谁编写了代码，是否所有人（包括自由职业者和供应商）都受权利转让协议约束
• 使用了哪些开源组件，其许可证是什么
• 在出售或作为服务运行的产品中是否有强著佐权组件
• 是否有代码复制自许可证不明的来源
• 源代码是否存放在公司控制的仓库中，且有清晰的变更历史
• 是否发生过知识产权主张或纠纷

已经有组件清单、许可证政策和整洁的权利转让合同的公司，几天内就能回答所有这些问题。没有的公司常要花数周去追溯和修复，有时还要付出成本并导致估值下降。

企业的实用步骤

1. 审查正在履行的供应商合同：检查是否有关于权利转让和源代码交付的条款。

2. 确保项目代码存放在以贵公司名义建立的仓库中，访问权限由您掌控。

3. 向供应商索取组件和许可证清单，并将其纳入交接内容。

4. 起草一份带有绿、黄、红清单的一页纸许可证政策。

5. 在开发流程中启用自动许可证扫描。

6. 确保所有贡献者（包括自由职业者）签署明确的权利转让或许可协议。

7. 在应用或文档中展示必须的署名。

8. 每年复查一次，或在融资和出售公司之前复查。

对于计划把项目转交给另一家供应商的企业，这些步骤也能简化交接，正如挽救停滞的软件项目与更换供应商一文所讨论的。

常见问题

使用开源是否会迫使我们的应用必须开源？不会自动如此。宽松许可证并不要求这样做。公开代码的义务主要出现在强著佐权许可证下，并且只在特定条件下，例如产品被分发时，或对 AGPL 而言，作为网络服务运行时。

我们付费请供应商开发的代码，是否自动归我们所有？不一定。所有权取决于合同和适用法律。因此，请在项目开始前明确写下权利转让或许可。

如果发布之后才发现有问题组件怎么办？评估问题有多大，然后选择路径：替换组件、如有商业许可证则购买，或调整架构。请法律顾问参与。发现得越早，修复成本越低。

本文足以作为法律依据吗？不能。它是帮助理解这些问题的一般性指南。决策和合同措辞应由了解您所在司法辖区知识产权法的法律顾问审阅。

结论

开源以低成本提供了世界一流的技术，但每个组件都附带条件。定制代码的所有权同样不能想当然。凭借关于权利转让和源代码交付的清晰合同、带许可证的组件清单、简单的许可证政策和自动扫描，公司可以享受开源的好处而不遭遇法律意外。尽早做这些事的成本很小，而在尽职调查或纠纷中补救的成本要大得多。