开源协议常识实用建议：选证避坑与合规要点

同事把一段从 GitHub 拷来的开源工具函数贴进公司项目，几周后法务问起许可证，协议选证大家才发现那个仓库用的常识是 GPL。代码已经上线，实用重写成本不小。建议这类麻烦多半不是避坑技术问题，而是合规开源协议常识没跟上。下面按实际工作场景，开源说几条能直接照做的协议选证建议。

先弄清三类常见许可证的常识差别

开源协议有几十种，日常遇到最多的实用是 MIT、Apache 2.0 和 GPL 系。建议可以把它们粗分为三档来记。避坑

宽松型以 MIT、合规BSD 为代表：保留版权声明和许可声明，开源基本可以商用、修改、闭源分发。Apache 2.0 也属宽松型，但多了专利授权条款和变更说明要求，用的时候要保留 NOTICE 文件。

弱著佐权以 LGPL、MPL 为代表：修改了库本身要开源，但只是调用它、不修改源码，通常可以保持自有代码闭源，具体边界以许可证原文为准。

强著佐权就是 GPL、AGPL：分发基于它的作品，整体要按同一协议开放源码。AGPL 还额外覆盖网络服务场景，把代码部署成在线服务也可能触发义务，做 SaaS 的要特别留意。

这三档只是粗略认知，真正判断时一定回到仓库根目录的 LICENSE 文件或许可证全文，别只看 README 里的一句话。

引入依赖时的核查步骤

第一步，在仓库里找 LICENSE、LICENSE.md、COPYING 这类文件，确认协议名称和版本号。GPL 有 v2 和 v3 之分，义务不一样，不能混着看。

第二步，看依赖树。项目直接引用的库是宽松协议，它内部又依赖了 GPL 组件，风险照样传导过来。用包管理器的许可证扫描功能，比如 npm 生态的 license-checker、Python 生态的 pip-licenses，先出一份清单。

第三步，区分“用”和“改”。直接调用、链接、修改源码、再分发，四种动作触发的义务不同。拿不准时记录下仓库地址、协议版本、使用方式，交给法务或合规同事判断，这比自己猜要靠谱。

第四步，留痕。把第三方组件清单、协议文本、版本号写进项目文档，升级依赖时同步更新。真出问题时，这份记录就是最有力的说明材料。

几个容易踩的坑

一是以为“公开在 GitHub 上就等于随便用”。仓库公开不等于授权，没有 LICENSE 文件的项目，默认保留所有权利，严格说连复制都不行。

二是把“开源”和“免费商用”画等号。开源讲的是源码可得和许可条件，不是放弃版权，商用前要看清协议是否允许。

三是忽略协议兼容性。把 Apache 2.0 的代码并进 GPL v2 项目，可能产生冲突，混用前要确认双方条款能否共存。

四是只查主仓库不看子模块。很多项目通过 submodule 或打包产物带入第三方代码，扫描时要覆盖完整构建产物。

五是以为改了名字、换了变量就算“自己写的”。实质性改写仍可能构成衍生作品，判断标准看的是表达是否源于原作品，不是改了多少行。

什么情况别自己硬扛

涉及商业分发、对外提供服务、被投诉或收到律师函，这几种场景不要凭网上帖子下结论，直接找知识产权律师或公司法务。企业内部也可以先建立一份“允许使用的协议白名单”，把边界定在前面，比事后补救省事得多。协议条款可能随版本更新，具体义务以许可证原文和当地法律为准。

给一个可执行的收束：新项目初始化时先定白名单，引入依赖时跑一次许可证扫描，把结果和 LICENSE 文本归档，升级时复查。三步做完，绝大多数开源协议常识问题都能在源头拦住。