GitHub 开源许可证怎么选？MIT、Apache、GPL 等 7 种对比

选择 GitHub 开源许可证，不能只按“宽松到严格”排一条线。MIT、BSD 和 Apache 主要要求保留声明；MPL 关注被修改文件；LGPL 关注库及其修改；GPL 关注分发覆盖作品；AGPL 还增加网络服务场景的源码义务。实际使用前必须阅读仓库 LICENSE 原文。

先检查仓库有没有许可证

GitHub 通常会在仓库右侧或根目录显示 License。也可以直接查找 LICENSE、LICENSE.md 或 COPYING 文件。

7 种常见许可证对比

表格只列核心差异，不能覆盖例外、兼容性、专利、商标和依赖组合问题。

MIT、BSD-3-Clause 和 Apache-2.0

这三类都属于常见的宽松许可证。

MIT

允许复制、修改、分发、商业使用和再许可，核心要求是保留版权声明与许可证文本。它简短、兼容面广，适合希望降低复用门槛的项目。

BSD-3-Clause

与 MIT 类似，但增加“不使用作者或贡献者名称为衍生产品背书”的条款。项目宣传时不要暗示原作者认可你的产品。

Apache-2.0

除声明要求外，还明确包含专利许可与终止条款。分发修改版时需要标注改动，并按项目情况保留 NOTICE。涉及企业协作和专利风险时，Apache-2.0 常比 MIT 提供更完整的文本框架。

MPL、LGPL、GPL 和 AGPL

这四种许可证的开放义务作用范围不同，并不是简单的四级强度。

MPL-2.0：文件级开放

修改 MPL 覆盖文件并分发时，需要公开这些文件的源码；它们可以和其他许可证或闭源文件放在较大的作品中。

LGPL-3.0：主要保护库本身

LGPL 常用于软件库。闭源程序可以在满足条件时与 LGPL 库链接，但对库本身的修改通常需要开放，并要保留用户替换或重新链接该库的能力。

GPL-3.0：分发覆盖作品时提供源码

如果分发受 GPL 覆盖的程序或其衍生作品，通常需要以 GPL 提供对应源码。仅说“把开源部分源码给用户”可能不够，组合方式和作品边界需要具体判断。

AGPL-3.0：增加网络交互条款

AGPL 在 GPL 基础上处理网络服务场景。运行修改版并让用户通过网络交互时，也需要向这些用户提供对应源码的获取方式。

给自己的项目怎么选

创建仓库时，GitHub 可以生成标准许可证模板。操作流程见 如何创建并开源第一个项目；拿到陌生项目后，先结合 GitHub 四种下载方式 判断你是在安装、检查、开发还是准备贡献。完整路线见 GitHub 零基础教程。

使用边界：许可证义务取决于使用、修改、链接、分发和网络服务方式；下表是工程决策摘要，不替代许可证原文或法律意见。