1.1 开源许可证的定义、法律效力与适用边界
我第一次认真看开源许可证，是在一个深夜排查构建失败的时候。项目里引入了一个小工具库，代码跑得好好的，可法务同事发来一封邮件，问“这个MIT许可证的声明文件在哪”。我当时就愣住了——原来代码开源，不等于随便用，许可证就是那根看不见的线。说白了，开源许可证是一份具有法律效力的授权合同。它由版权持有人发出，允许你在特定条件下使用、修改、分发软件。你接受了这些条件，才拿到授权；你不接受，默认的版权法就拦在前面。
这事的关键在于，许可证的效力来自版权法，不是来自什么口头承诺。没有许可证的代码，法律上就是“保留所有权利”，哪怕它公开在GitHub上。我见过不少团队在这上面翻车：直接复制粘贴一段代码，以为没写许可证就是公共领域。适用边界也值得留意——许可证管的是版权层面的复制、修改、分发行为，它管不到商标使用，也管不到专利侵权（除非许可证里明确写了专利授权条款）。我经常提醒身边的朋友：读许可证，先搞清楚它授权了什么、没授权什么。
1.2 许可证类型图谱：宽松型、著佐权型与弱著佐权型
用我自己的话说，开源许可证大致能画成一张三层的图谱。最上面是宽松型，MIT、BSD、Apache 2.0 都算这一类。它们对衍生作品的要求很松，你改了代码、闭源发布，基本没人拦你，只要保留版权声明就行。我早期做外包项目特别喜欢用MIT，省心，客户也挑不出毛病。但宽松型不强制你开放源代码，这意味你的改动可以藏起来，社区拿不到回馈。
中间一层是弱著佐权型，LGPL 和 MPL 2.0 是典型代表。它们要求对“许可证覆盖的那部分代码”的修改必须开放，但你把它链接到一个更大的专有程序里，那个程序不必开源。这个边界挺微妙的，我花了很久才搞明白 LGPL 的动态链接和静态链接差别有多大。最下面一层是强著佐权型，GPL 和 AGPL 是标准答案。它们要求衍生作品整体以同样的许可证发布，代码必须开放。AGPL 更进一步，把网络服务也算作分发，SaaS 场景下用 AGPL 组件，你得特别小心。
这张图谱不是拿来背的，是拿来判断“传染范围”的。我有个习惯，拿到一个依赖列表，先按这三层分类，宽松型放一堆，著佐权型放另一堆，心里就有数了。不然等到产品要闭源交付，才发现自己踩进了GPL的圈，那真是连夜改架构的节奏。
1.3 开源许可证指南中的核心术语：版权声明、专利授权、商标、免责与再分发
我刚开始看许可证文本的时候，满眼都是大写英文，头都大了。后来发现，抓住几个核心术语，整份文本就通了。版权声明是最基础的一条：你得保留原作者的版权信息，不能删。我见过有人把别人代码里的版权头直接抹掉，换成自己的名字，这已经不只是合规问题了，属于明晃晃的侵权。
专利授权是很多团队容易忽略的部分。Apache 2.0 里明确写了贡献者授予你专利许可，MIT 里没有这句话。这个差别在商业场景下挺要命的——万一你用的库涉及专利，许可证里没写专利授权，贡献者回头告你专利侵权，你连挡箭牌都没有。商标条款也是常被误解的地方，开源许可证一般不授权你使用项目方的商标，哪怕你改了代码做了衍生品，也不能打着原项目的旗号去宣传。
免责条款读起来像法律套话，但它保护的是贡献者——软件出问题，贡献者不担责。再分发条款则规定了你能不能把软件再发出去、需要附带什么文件。我现在的习惯是，每引入一个新依赖，先把这几项在脑子里过一遍：版权声明留了吗、专利授权有没有、商标能不能用、免责范围多大、再分发需要带什么。这五问帮我避开了不少坑。
1.4 常见合规风险与误区：许可证兼容性、传染范围与商业使用
合规风险里，许可证兼容性是最隐蔽的一个。我去年帮一个团队做代码审计，发现他们同时用了 GPL 的组件和 Apache 2.0 的组件，还打算整体闭源分发。这两类许可证在兼容性上是有冲突的，GPL 要求整体开源，Apache 2.0 的部分没法满足这个条件。当时他们一脸茫然，觉得“都是开源许可证，怎么还会打架”。兼容性这事，得看许可证条款之间有没有矛盾，不是说名字都叫开源就能随便拼。
传染范围是另一个高频误区。很多人以为 GPL 只管“直接修改的那几个文件”，实际上衍生作品的认定范围要看具体的使用方式。动态链接、静态链接、进程间通信，每种方式的法律解释都不一样。我自己踩过一次坑：把一个 GPL 库静态链接进项目，以为主程序可以闭源，结果被社区提醒后才明白，静态链接通常被视为衍生作品，整个程序都得按 GPL 发布。
商业使用这块，误区更多。开源许可证不等于“不能商用”，MIT、Apache 2.0 都允许商业使用，甚至允许你卖了赚钱。问题出在“商用”和“闭源”经常被混为一谈。GPL 也允许商用，只是要求你开源。我经常跟人解释：你可以卖基于 GPL 的软件，但买了软件的人有权拿到源代码。搞清楚许可证到底限制了哪一步，比笼统地说“能不能商用”要有用得多。
2.1 GPL与MIT许可证区别：授权条件、源代码开放义务与衍生作品范围
我头一回被GPL撞了一下腰，是帮一个创业团队做技术选型。他们想用一个挺流行的图像处理库，功能对口，社区活跃，结果我翻到LICENSE文件第一行写着GPLv2，心里咯噔一下。不是说不能用，问题是他们的产品打算闭源卖给企业客户。GPL的核心就一句话：你分发基于它的衍生作品，整个作品都得按GPL开放源代码。注意，是“整个作品”，不是“你改的那几个文件”。这条款叫“传染性”，名字听着吓人，法律上叫“著佐权”——用版权手段强制后续作品保持开源。
MIT就完全是另一个画风。整份许可证短得能一口气读完，核心就一句：你爱怎么用怎么用，改也行、卖也行、闭源也行，只要把版权声明和许可声明留下来。我手头好几个商业项目都靠MIT组件撑着，客户交付时附一份LICENSES.txt就完事，法务那边基本不卡。MIT不要求你开放源代码，也不问你衍生作品怎么定义。它把“自由”给了使用者，代价是社区拿不到你的改进回馈。这件事我想过很久，选MIT本质上是在“省事”和“回馈”之间做取舍，没什么对错。
衍生作品的范围是这俩许可证最要命的差异点。GPL的边界模糊得让人头疼，动态链接、静态链接、进程间通信，不同法院和社区解释还不完全一致。我自己的经验法则偏保守：只要你的代码和GPL组件编译进同一个二进制、或者以函数调用方式紧耦合，就当衍生作品处理，按GPL走。MIT压根不跟你讨论衍生作品范围，它连“衍生作品”这个词都懒得定义，你改完了爱怎么处置怎么处置。这种“不定义”反而让企业法务安心——没有模糊地带，就没有合规焦虑。我现在给团队做培训，常说一句话：GPL是“你得跟我一样开放”，MIT是“你随意，记得提我名字”。
