你写的代码里，藏着一份没读过的开源许可证

晚上十一点，南京的秋风从窗户缝里钻进来，有点凉。我盯着屏幕上一个报错，顺手 npm install 了一个包。装完，鬼使神差地点开了 node_modules 里那个叫 LICENSE 的文件。

乖乖。以前我从来不看这玩意儿。

那一刻我才发现，开源许可证压根不是什么情怀宣言，它是一份正经的授权合同。你用了别人的代码，就等于签了字。只是大多数人，包括以前的我，连条款都没翻过。

GitHub仓库根目录LICENSE文件截图

那个叫 LICENSE 的文件，真不是摆设

很多人对开源有个特别朴素的误解：代码放到网上，就是大家的，我想怎么用就怎么用。

哪有这种好事。

有点像你去朋友家吃饭。朋友说“随便吃”，你可以夹菜，可以添饭。但你不能把人家锅端走，更不能把菜谱印成书拿去卖。开源许可证就是那张写着“随便吃”到底有多随便的纸条。

常见的就那么几个。MIT、Apache 2.0、BSD、GPL、LGPL、AGPL。名字看着像乱码，其实区别就一件事：你用了我的代码之后，必须遵守什么规矩。

Apache 2.0 跟 MIT 有点像，但多了一层专利授权。如果你在公司写代码，法务一般会喜欢 Apache 2.0，因为它把专利风险讲得比较清楚。

然后就是 GPL。这个家伙，名声在外。

GPL 的核心是“传染性”。你用了 GPL 的代码，并且对外分发你的软件，那你的整个软件也得用 GPL 许可证，源代码也得公开。注意，是分发的时候。你自己在家里玩，没人管你。但你一旦打包卖钱，或者发布出去，规则就启动了。

我有个朋友，做桌面软件的。有次为了赶进度，塞了一个 GPL 的库进去。后来软件要卖，被懂行的用户提醒了一句。他当时脸都白了。连夜找替代方案，一边找一边骂：这玩意儿怎么跟螺蛳粉一样，沾上就一身味儿。

LGPL 稍微温和一点。它主要针对库。你动态链接 LGPL 的库，自己的代码可以不开源。但你要是改了库本身，那部分改动得开源。AGPL 更狠，它把网络服务也算作分发。你用 AGPL 的代码做网站，用户通过浏览器访问，也可能触发开源义务。做 SaaS 的团队，看到 AGPL 一般会绕着走。

这是另一个重灾区。

GitHub 上很多仓库，README 写得挺热闹，代码也公开。但根目录就是没有 LICENSE 文件。很多人一看，没许可证，那不就是公共领域？随便用。

错得离谱。

没有许可证，默认版权归作者所有。你只能看，不能复制，不能修改，不能分发。你想用，得发邮件问作者。作者回你一句“可以”，那才叫授权。不回，你就别用。

我就干过这种蠢事。早年写一个爬虫，从网上抄了一段代码，那个仓库没写许可证。我当时想，反正没人管。后来项目要开源，我才慌慌张张回去翻。幸好那段代码最后被我重写了。现在想想，有点后怕。

所以，如果你打算把自己的代码开源，第一件事就是加一个 LICENSE 文件。别让别人猜。MIT 也好，Apache 2.0 也好，选一个你看着顺眼的。你要是什么都不写，别人想帮你推广都不敢，因为法律上站不住脚。

你不是程序员？没关系。你公司用的软件，你做的网站，甚至你买的智能音箱，里面都可能藏着开源代码。许可证一旦出问题，轻则被要求开源，重则吃官司。不是开玩笑。

如果你写代码，记住几条保命原则。

最省事的办法，是引入任何第三方库之前，花三十秒看一眼它的 LICENSE。别嫌麻烦。三十秒换一夜安眠，值。

还有一个坑，公司项目尽量用 MIT、Apache 2.0、BSD 这类宽松许可证的库。GPL 和 AGPL 不是不能用，但要清楚代价。你要是做闭源商业软件，用了 GPL，基本等于给自己埋雷。

别以为改几行代码就能绕开许可证。GPL 的传染性看的是衍生作品，不是看你改了多少行。你链接了，你集成了，都可能被算进去。具体边界当然有争议，但别赌。

如果你自己开源，选许可证之前想清楚。你想让别人随便用，就 MIT。你想让所有衍生作品都保持开源，就 GPL。你想兼顾专利，就 Apache 2.0。没有最好的许可证，只有最适合你目的的许可证。

话说回来，开源许可证这个东西，平时看不见摸不着。一旦出事，就是大事。它像马路上的交通规则。你天天闯红灯没事，不代表红灯不存在。哪天撞了，才想起来交规没看。

所以，下次你打开一个开源项目，别只盯着 star 数。点开那个 LICENSE 文件，看一眼。真的，就一眼。

南京的夜越来越深了。我关掉编辑器，心想，明天得把公司那个老项目的许可证全部过一遍。不然，觉都睡不踏实。