开源协议踩坑后，我用三步小成本试错

“你这个仓库用了 GPL 的开源库，怎么还挂 MIT 协议？协议”同事在代码评审时随口一问，我当场愣住。踩坑成本那是后用个内部工具，本来只打算小范围用，试错后来被别的开源团队拿去改，我才意识到协议问题不是协议“以后再说”的事。

下面按时间顺序复盘我那次失手，踩坑成本以及后来总结出的后用低成本试错动作。它不保证法律上万无一失，试错但能帮你在写代码之前就把大部分明显问题筛掉。开源

第一步：新建仓库时先看依赖的协议协议文件

失手那天，我是踩坑成本在项目上线前一周才去看依赖。正确顺序应该反过来：建仓库、后用装第一个依赖之前，试错先打开它的 LICENSE 或 COPYING 文件。不用通读全文，先确认三件事：协议名称、版本号、有没有附加条款。

具体动作是：在依赖目录里找 LICENSE、LICENSE.md、COPYING 这类文件；找不到就去项目主页的仓库根目录看。如果只有一行“MIT”，那基本是宽松协议；如果写着 GPL-2.0、GPL-3.0、AGPL，就要停下来想清楚你的项目要不要公开源码。

这一步成本很低，五分钟能看完一个依赖。难的是坚持每个新依赖都做一遍，而不是等出问题再补。

第二步：用一张表把“我改了什么”记下来

我第二次踩坑，是把一个 MIT 协议的组件改了十几行，然后直接放进闭源项目，忘了保留原版权声明。问题不在于改代码，而在于没记录改动范围和原始声明。

后来我固定用一张很土的表：依赖名、协议、是否修改、是否分发、原始版权声明放在哪。每次引入新库就填一行。修改过的文件，在文件头保留原版权行，并注明“modified by …”。这不是形式主义，而是日后有人问起时，你能说清楚哪些是别人的、哪些是自己的。

如果项目要对外分发，这张表还能帮你快速判断：哪些依赖要求你公开源码，哪些只要求保留声明。关于开源协议常识，很多争论其实卡在“有没有分发”这个动作上，而不是协议本身多复杂。

第三步：拿一个空仓库做最小分发演练

真正让我踏实下来的，是做一次低成本试错：新建一个空仓库，只放一个依赖和一个入口文件，模拟对外发布。走一遍流程：打包、附上 LICENSE、检查产物里有没有遗漏的声明文件。

演练时重点看两处。第一，构建产物里有没有把依赖的协议文件带进去；第二，你的项目协议和依赖协议有没有明显冲突，比如把 GPL 代码放进闭源分发物。发现冲突就换依赖，或者把该部分拆成独立进程、独立仓库，而不是硬扛。

这套演练不需要真实用户，也不需要法务在场，一个人半小时能跑完。它的价值在于把“协议”从抽象条款变成构建步骤里的一个检查项。

拿不准时，把问题缩小到一个依赖

我现在遇到不确定的协议，不会去搜“XX 协议能不能商用”这种大问题，而是把范围缩到一个依赖、一个分发场景、一个具体动作：我是内部使用还是对外发布？有没有修改？有没有把源码给出去？这三个答案不同，结论往往不同。

如果仍然拿不准，就去查该协议的官方文本，或者找公司法务、知识产权律师确认。开源协议常识能帮你排除明显错误，但不能替代针对具体项目的法律意见。低成本试错的意义，是让你在花大钱之前先发现那些本来可以避免的失手。