窗口快叫号了，开源协议怎么快速判个大概

最常见的窗口卡住，不是快叫看不懂法律条文，而是号开把顺序做反了：先在搜索结果里翻长篇译文，再纠结“商用要不要付费”，源协议快等号叫到了还没弄清这个项目到底允不允许改完闭源。速判正确的个大概顺序恰好相反——先确认你拿到的是哪份协议文本，再看你打算怎么用它，窗口最后才去读那两三条真正卡住你的快叫条款。

先认名字，号开不要先读全文

夜里赶时间，源协议快第一步只做一件事：在项目根目录找 LICENSE、速判LICENSE.txt、个大概COPYING 这类文件，窗口打开第一屏，快叫记下协议名称和版本号。号开名字比内容重要，因为同名不同版本差别很大。看到 MIT、BSD 二或三条款、Apache 2.0、Mozilla Public License 2.0、GNU 通用公共许可证的某个版本，先照抄名字，不要凭印象归类。

如果文件不存在，或者只在 README 里写一句“本项目采用某协议”，先当作“授权不明”处理。授权不明时，默认不能复制、修改、再分发，这是版权法的基本盘，不是吓唬人。赶时间的做法是：先找仓库的发布页、包管理器的元数据字段，两处对照；两处一致，才敢往下判断。

只回答一个问题：改完之后要不要公开

这是开源协议常识入门里最省时间的一刀。你只需要判断两件事：你是原样分发，还是改了再分发；你的成品是否要和原项目一起对外提供。

MIT、BSD、Apache 2.0 这类宽松协议，通常允许你修改后闭源分发，义务集中在保留版权声明和许可文本。Apache 2.0 还额外要求你说明改动、带上 NOTICE 文件（若有），并涉及专利授权条款。GPL 系列则要求你把对应源码以同一协议提供给接收方；LGPL 在动态链接等场景下有更细的边界。MPL 2.0 是按文件来的，改到哪个文件就公开哪个文件。

注意这里的措辞是“通常”“一般”，因为具体到链接方式、插件结构、分发形式，结论会变。赶时间时不要自己推演到底，先把“要不要公开源码”这个答案记下来，标成待核。

三个能当场做完的动作

第一，把协议名、版本、你拿到的来源（仓库地址或包名）写进一行记录。第二，判断你是否在分发：只在自己电脑上跑，和把程序交给客户，是两回事。第三，看有没有附加条款：有些项目在标准协议之外加了 Commons Clause、附加使用限制，或者双许可证，这些会推翻你对标准协议的记忆。

做不完就停在这里，不要硬凑结论。窗口叫号时，你需要的是一句可交代的话：“这个组件是 Apache 2.0，我们修改后随产品分发，需要保留声明和 NOTICE，源码公开义务待确认。”这句话足够让后续的人接手。

拿不准时的下一步，别在现场死磕

如果项目没有协议文件、协议名写法含糊、或者你分不清 GPL 与 AGPL 的差别，处理方式是换组件或走内部审批，而不是当场猜。AGPL 的关键点在于网络服务场景，这一点光看名字看不出来，值得单独核。

需要权威口径时，去看协议原文和项目方声明，而不是二手解读；涉及商业分发、专利、合规责任，找法务或知识产权方向的专业人士，别让工程师独自签字。开源协议常识入门的最小步骤，说到底就是：先认名字和版本，再答“改完要不要公开”，把不确定项写清楚交出去。做完这三步，你至少不会在窗口前给出一个自己都不信的答案。