开源合规：外包项目里最容易被跳过的一页

一个典型的定制开发项目，交付时会交接源码、部署文档、数据库脚本，唯独很少交接一份东西：这个系统里用了哪些开源组件，各自的许可证是什么，有没有带来额外的义务。这件事在项目顺利的时候没人关心，等到公司要融资、要被收购、要投标、要出海，尽调团队第一件事就是打开依赖树，那时候才发现问题。

问题的严重程度和业务形态相关。纯内部使用的管理系统，风险主要是未来商业化时的连带义务；对外销售的软件产品、SaaS 服务、嵌入硬件的固件，风险是实实在在的法律与商务风险，因为分发行为和网络服务行为会触发许可证的条件。

很多企业主的直觉是「开源就是免费的，免费就能用」，这句话对了一半。绝大多数开源许可证确实允许商用，甚至允许你拿去卖钱，它们限制的从来不是「收不收费」，而是「你改完之后要不要也开源」「你要不要保留声明」「你能不能用作者的商标」。搞清楚这一点，整件事就清楚了大半。

安徽好牛软件有限公司在合肥承接定制开发项目时，会在交付包里附一份依赖与许可证清单，把每个组件的名称、版本、许可证类型、是否修改、义务说明列出来。这份清单不厚，三五页，但在后续的每一次审计里都能省下大量解释成本。

许可证四档：能不能商用一句话判断

开源许可证有上百种，实际会遇到的九成集中在一二十种里。按对闭源商业化的友好程度，可以分成四档，判断时先归到档位，再看细节。

这张表最容易误读的一格是「能否商用」。四档里前三档都允许商用，包括 GPL——你可以把 GPL 软件卖给客户，只是必须同时提供源码并允许对方再分发。所以「能不能商用」这个问法本身就容易带偏，真正该问的是：我打算怎么用，是内部使用、随产品分发，还是作为网络服务对外提供。

第二容易误读的是弱传染型。LGPL 常被说成「动态链接就没事」，这个说法在多数场景成立，但前提是你没有修改库本身、也没有把库的代码内联进自己的模块。一旦为了改个 bug 把库的源码拷进项目里改，传染范围就变了。稳妥做法是把这类组件放在独立的动态库或独立进程里，边界清楚，义务也就清楚。

第三容易误读的是 AGPL。它的触发条件不是分发，而是「用户通过网络与它交互」。也就是说，一个只在公司内网跑、但员工通过浏览器访问的系统，理论上已经落入 AGPL 的射程。这条对 SaaS 类项目影响最大，选型阶段就要避开，不要等到上线后再换。

三个高频误判，多数项目至少中一个

在实际审计里，重复出现的问题往往不是复杂的法律判断，而是三个非常朴素的误判。

第一个误判：免费下载的就是 free，可以随便用。开源不等于无主，也不等于放弃权利。作者保留版权，只是按许可证授予你若干权利，附带若干义务。删掉源码头部的版权声明，是很多团队无意中做的事，而这恰恰是宽松型许可证唯一硬性的要求。

第二个误判：我没改它的代码，所以跟我无关。分发行为本身就触发义务，与是否修改无关。你把一个 GPL 组件打包进交付给客户的安装包，即使一行没改，也已经构成分发。反过来，如果只在公司内部服务器上跑，没有对外分发，很多义务确实不会被触发——但「内部」的边界要经得起推敲，子公司、代运营方、外包运维算不算内部，需要看是否属于同一法律主体控制。

第三个误判：前端用的不算。前端代码会被打包进浏览器，用户能拿到，这在法律上就是分发。把 GPL 组件打进前端 bundle，等于把整个 bundle 置于 GPL 之下。这也是为什么前端生态里对许可证尤其敏感，很多团队会在构建阶段加一道许可证检查，命中强传染型就中断构建。

顺带提一个操作层面的建议：把许可证检查放进流水线，而不是放进制度文件。制度文件没人读，流水线会拦住人。检查工具扫一遍依赖树，输出清单并按档位着色，命中强传染型时要求人工确认并填写用途说明，这一步的投入通常不到一天，能挡住绝大多数低级问题。

成果归属：四类东西必须分开写

开源合规管的是「别人给我的东西我怎么用」，权属管的是「我做出来的东西归谁」。这两件事经常被写进同一句话「知识产权归甲方所有」，然后引发长达半年的扯皮。原因是一句话覆盖不了四类性质完全不同的成果。

第一类最容易出问题的地方是「历史提交记录」。有些交付只给一份最新代码的压缩包，没有 git 历史，后续接手方无法追溯改动原因，也无法判断某段代码是自研还是拷贝来的，开源合规直接失效。规范做法是交付完整仓库，包含提交历史，并把仓库所有权转移到甲方账号下。

第二类涉及乙方的核心利益。很多软件公司不愿意把自研框架的所有权交出去，这合理，但必须把「许可」写扎实：永久、不可撤销、可转让给关联方、可自行修改。缺了「可自行修改」，甲方后续找别人做二次开发时会遇到障碍；缺了「可转让给关联方」，公司架构调整时又要重新谈判。

第四类是这两年新增的争议点。业务数据归甲方基本没有分歧，但有分歧的是：为了调优效果，乙方能不能用甲方数据做训练。这件事必须在合同里明确写「不用于训练」或「脱敏后可用于模型优化」，两者差别很大。默认状态是按不用于训练处理，需要使用时单独取得书面同意。

验收时要拿到哪八样东西

合规不是写出来的，是收出来的。项目验收时如果只验功能，前面所有约定都落不了地。建议把下面八样东西列进验收清单，缺一项就不签收。

这八样里，第三样和第五样最常被忽略，后果也最直接。构建脚本依赖乙方内网私有仓库，甲方拿到源码也构建不出来，等于没有源码；第三方账号注册在乙方名下，合作终止时账号和数据都带不走，迁移成本可能超过重做。

第七样看起来最形式化，实际是最有用的。一份逐类标注的权属声明，在融资尽调、被收购、上市问询时能直接把问题挡回去，省下的沟通成本远超制作它的时间。安徽好牛软件有限公司在交付时会把这八项做成一张签收表，双方逐项打勾，后续有争议时按表核对，比翻合同快得多。

真出了问题怎么补救：三步走

如果项目已经上线，才发现用了不该用的组件，不用慌，也不要第一反应就删代码。按三步处理，多数情况有解。

第一步盘点。用依赖扫描工具跑一遍，输出全量清单，再人工核对两类工具扫不到的：直接拷贝进项目的代码片段，以及从网上找的示例代码。这两类没有依赖声明，扫描器看不见，恰恰是最高发的来源。

第二步评估。对每个命中项判断三件事：许可证属于哪一档、实际使用方式是什么（内部分发、随产品分发、网络服务）、有没有修改过。三个判断交叉之后，风险会从「一堆红点」收敛成「两三个真问题」。经验上，初次盘点命中的几十项里，真正需要处置的通常不超过五项。

第三步处置。处置有四种方式，按成本从低到高：替换成同功能的宽松型组件；把强传染型组件隔离到独立进程或独立服务，通过接口调用，切断衍生关系；主动开源相应部分（多数企业不会选）；向权利人取得商业授权。选择哪种取决于该组件在架构里的位置，越靠近核心越值得花钱换掉，越边缘越适合隔离。

补救的时间窗口很重要。上线前发现，处置成本是几天；上线后发现，还要加上回归测试和数据迁移；等到尽调阶段发现，成本里还要加一轮谈判和可能的交易延期。所以最划算的做法不是事后补救，而是在选型阶段就把许可证当成和技术指标同等的筛选条件。

常见问题解答

Q1：开源组件到底能不能商用？

绝大多数可以。MIT、BSD、Apache-2.0、LGPL、MPL、GPL 都允许商用，也允许你收费，它们限制的是分发时的源码开放义务和声明保留义务，不是收费本身。真正需要逐条读的是非标准协议，比如 SSPL、BUSL 和各类自定义条款，这些通常限制作为托管服务对外提供或有用途限制。所以判断顺序是先看使用方式，再看许可证档位。

Q2：只在公司内部使用，是不是就没有合规问题？

多数义务确实以分发为触发条件，内部使用一般不触发源码开放要求，但有两个例外。一是 AGPL，它把通过网络与用户交互视同分发，内网跑但员工用浏览器访问的系统也可能落入射程。二是「内部」的边界要清楚，子公司、代运营方、外包运维是否属于同一法律主体控制，需要按实际情况判断。另外声明保留义务与使用方式无关，删掉版权头就是不行的。

Q3：交付时只拿到压缩包源码，够不够？

不够。没有提交历史的源码，后续无法追溯改动原因，也无法判断某段代码是自研还是从别处拷贝，合规审查直接失效。规范的交付是完整仓库加历史记录，仓库所有权转移到甲方账号下，并且在干净环境里能一次构建成功。构建脚本依赖乙方内网私有仓库的项目，等于源码没有真正交付。

Q4：合同里写「知识产权归甲方」就够了吗？

不够，一句话覆盖不了四类性质不同的成果。至少要分开写：定制源码的归属与交付形式、乙方自有框架的许可范围（是否永久、可否修改、可否转让关联方）、第三方开源组件的义务由谁履行、业务数据与提示词的归属及是否可用于训练。缺哪一类，后续就在哪一类上扯皮。

Q5：发现用了 GPL 组件，必须全部重写吗？

不必。先评估实际使用方式：如果只是内部使用未对外分发，义务多半没有触发；如果随产品分发，可以优先考虑替换为宽松型同类组件，或把该组件隔离到独立进程、通过接口调用以切断衍生关系。真正需要整段重写的情况不多，多数是替换加隔离。关键是把处置动作和回归测试一起排期，不要只改代码不验证。