小王接了个外包单子，想用 GitHub 上一个挺火的 Python 工具快速开发后台管理模块。他 fork 了项目、改了几行代码，打包进自己客户系统里就上线了——结果两周后收到律师函，对方是原作者委托的版权代理。
开源 ≠ 免费商用
很多人一看到“开源”俩字，下意识觉得“谁都能用、随便改、还能卖”。其实不是。开源只是代表源码公开可查，能不能商用、能不能闭源、要不要署名，全看它挂的是哪张“许可证”。就像你进小区，门开着不等于你能随便住进去，得先看清门口贴的《住户守则》。
主流许可证怎么管商用？
最常遇到的几个许可证，差别挺大：
MIT 许可证：最宽松。你可以拿它做任何事——改、卖、闭源、集成进商业软件，唯一要求是保留原作者版权声明。比如：
Copyright (c) 2023 John Doe<br>Permission is hereby granted...<br>THE SOFTWARE IS PROVIDED "AS IS"...Apache 2.0：比 MIT 多一条：如果你修改了它的代码并分发（比如打包进你的 App），得在文档里说明你改了哪些地方。但依然允许商用、闭源、卖钱。
GPL v3：这是个“传染型”许可证。如果你把 GPL 代码直接编译进自己的程序（比如静态链接），那整个程序也得按 GPL 开源——也就是说，你不能把它做成闭源收费软件卖。但如果是通过网络调用（比如调 API）、或者只运行在自己服务器上不发布二进制文件，那就不算“分发”，可以绕开限制。
举个真实例子
有个开发者用了一个基于 GPL 的 PHP 框架写电商网站，部署在自己服务器上，用户只访问网页。没问题，不用开源。但他后来把这套系统打包成“一键建站工具”，卖给别人安装使用——这就触发 GPL 分发条款了，必须公开全部源码，否则侵权。
AGPL：比 GPL 更狠。哪怕你只是把 AGPL 项目部署在云服务器上、让用户远程使用（比如 SaaS），也算“分发”，一样得开源。很多云服务公司会主动避开 AGPL 项目。
怎么一眼认出许可证？
别靠猜。打开项目主页或仓库根目录，找这几个文件名：LICENSE、LICENSE.md、COPYING。点开看看第一行是不是写着 MIT / Apache-2.0 / GPL-3.0 等字样。GitHub 仓库右上角也会显示许可证图标（带小写字母的彩色徽章），点一下就能跳转查看全文。
顺手提醒一句：有些项目写了“本项目仅供学习交流”，这种不算开源许可证，法律效力极弱，商用风险极高，建议直接绕道。
说到底，用开源代码前花三分钟读清许可证，比上线后再打官司省心多了。真要商用，优先选 MIT 或 Apache；想闭源卖钱又用了 GPL 项目？要么换掉，要么联系原作者谈商业授权——不少开源作者也收授权费，价格可能比你请人重写还便宜。