夜里被人催着选开源协议，两条路怎么分

晚上十点半，夜里源协议两测试环境刚跑通，被人群里有人问：“明天要给客户交代码，选开协议选哪个？条路”或者临下班前，法务窗口只剩二十分钟叫号，夜里源协议两你手里只有一份 README 和一行 LICENSE。被人这种时候，选开最怕的条路不是不懂，而是夜里源协议两把两种完全不同的做法混着用：一种是把协议当成“版权声明贴上去”，另一种是被人把它当成“项目治理规则来设计”。两者都能从零开始做开源协议常识，选开但适用边界差得很远。条路

先分清：贴一份现成协议，夜里源协议两还是被人自己改条款

第一种做法是直接选用成熟协议，比如 MIT、选开Apache-2.0、GPL 系列，把原文放进仓库根目录的 LICENSE 文件，再在 README 里写清楚项目名称和年份。它适合大多数个人项目、内部孵化后对外释放的小工具、以及公司允许“标准协议白名单”的场景。选错的后果通常不是法律灾难，而是沟通成本：你贴了 MIT，却在文档里写“商用需授权”，两边矛盾，对方法务会直接退回。

第二种做法是根据业务改条款，比如加“不得用于竞品”“商用需单独签约”。它适合有明确商业化边界、需要保留商标和专利授权的项目。但边界也很硬：改过的文本不再是标准协议，别人无法一眼判断义务，社区贡献者会犹豫。更现实的风险是，你改了却没说清哪些是新增限制，下游把项目当标准 MIT 用，后面再纠正就很被动。

判断标准可以很具体：如果明天就要交付、团队没有法务复核时间，优先选成熟协议原文，别在 LICENSE 里夹带自拟句子；如果项目本身要融资、要双许可、要保留专利池，才进入自拟条款的流程，并且把“这不是标准协议”写在显眼位置。

看仓库里的三个文件，别只看协议名

从零开始做开源协议常识，最容易被忽略的是协议之外的配套文件。夜里赶工的人常只放一个 LICENSE，第二天对方问“贡献者许可怎么处理”，才发现缺东西。比较稳妥的动作是同时检查三处：根目录的 LICENSE 是否是完整原文，README 里的“License”段落是否只做引用而不另写一套规则，以及是否有 CONTRIBUTING 说明贡献者提交代码时默认接受什么条款。

这里有个具体例子：一个前端组件库用了 Apache-2.0，但 README 里写“禁止删除作者署名”。Apache-2.0 本身有署名和变更说明的要求，额外加一句并不会自动变成有效附加条款，反而让使用者不知道以哪个为准。正确动作是把额外要求放进 NOTICE 或单独的商标政策，而不是塞进协议段落。选错这一步的后果是：代码能用，但对方合规审查卡在“声明不一致”上，交付时间反而被拖长。

交付窗口叫号时，先确认依赖树再签字

还有一种并排对照常被混淆：只给自研代码选协议，和把整个依赖树一起交付。前者只处理你写的部分；后者要确认第三方库的协议是否允许你再分发。窗口叫号时，工作人员通常只看你提交的清单，不会替你查 node_modules。可行动作是先导出依赖清单，标记出 GPL 类、AGPL 类和“商用需授权”的条目，再决定是替换、隔离还是单独说明。

如果时间只够做一件事，优先确认“有没有 copyleft 依赖被静态链接进交付物”。这不是吓唬人，而是选错后最常见的返工点：你给主项目选了 MIT，但某个依赖是 GPL，整体分发方式就可能需要调整。拿不准时，把依赖清单和交付方式写成一句话，交给公司法务或官方知识产权窗口确认，不要靠群里投票。

两条路的分界其实很清楚：成熟协议原文解决“别人能不能用、怎么用”的通用问题；自拟条款和依赖审查解决“这个项目特有的商业边界”问题。夜里赶时间，先把前者做干净，后者留到有复核条件时再动。协议文件不是装饰，它得和 README、NOTICE、依赖清单对得上，交付时才不用回头改第二遍。