如何在GitHub仓库中添加MIT开源许可证

一、引言：你的开源项目，真的“开源”了吗？

你满怀激情地在GitHub上创建了一个新项目，并公开了所有源代码。你认为它已经是“开源”的了，任何人都可以自由使用。但事实真的如此吗？

答案是：不一定！

根据国际版权法，如果你的代码没有明确的许可证（LICENSE），它就处于默认的“保留所有权利”（All Rights Reserved）状态。这意味着，从法律上讲，其他人不能合法地使用、复制、修改或分发你的代码。这无疑与你的开源初衷背道而驰。

添加一个开源许可证，就像是为你的项目颁发了一张“通行证”。其中，MIT许可证以其极度的简洁和宽松，成为了最受欢迎的开源协议之一。本文将通过图文并茂的方式，手把手教你如何在GitHub网页上，为你的仓库添加标准的MIT许可证。

---

二-A：【推荐场景】为已存在的仓库添加许可证

这是最常见的情况：项目已经创建好了，但你后知后觉地发现忘记添加LICENSE文件。

步骤 1：进入你的仓库主页，点击“添加文件”

打开你的目标GitHub仓库。在文件列表的右上方，找到并点击绿色的 Add file 按钮，然后从下拉菜单中选择 Create new file。

[图片：GitHub仓库主页，高亮显示Add file按钮及其下拉菜单中的Create new file选项]
图1：创建新文件

步骤 2：触发“魔法”按钮

这是最关键的一步！在文件名的输入框中，准确地输入 LICENSE（大小写均可，但大写是行业惯例）。

当你输入这个特定的文件名后，你会发现页面右侧神奇地出现了一个“Choose a license template”（选择许可证模板）的按钮。

[图片：创建新文件页面，文件名输入框中已填入LICENSE，右侧的Choose a license template按钮高亮显示]
图2：输入“LICENSE”后，模板按钮自动出现

步骤 3：选择 MIT 许可证模板

点击 Choose a license template 按钮。GitHub会带你进入一个模板选择页面。

在左侧的列表中，找到并点击 MIT License。

[图片：许可证模板选择页面，左侧列表中高亮显示MIT License]
图3：从模板列表中选择MIT许可证

步骤 4：检查并提交文件

点击后，右侧的文本编辑器会自动填入标准的MIT许可证文本。更棒的是，GitHub已经智能地帮你填好了 [year] (年份) 和 [fullname] (你的GitHub用户名或组织名)。

你完全不需要做任何修改。直接滚动到页面底部，点击绿色的 Commit changes... 按钮。

[图片：自动填充好的MIT许可证文本，以及页面底部的Commit changes...按钮]
图4：自动生成的许可证文本和提交按钮

步骤 5：确认提交

最后，你会进入一个提交（Commit）页面。通常你不需要修改默认的提交信息（例如 “Create LICENSE”）。
直接点击页面底部的绿色 Commit changes 按钮。

[图片：提交确认页面，显示默认提交信息和最终的Commit changes按钮]
图5：确认最终提交

大功告成！ 你的仓库现在已经包含了一个标准的LICENSE文件。刷新仓库主页，你会在右侧的“About”区域看到一个盾牌图标和“MIT License”的字样。

[图片：仓库主页右侧，显示MIT许可证的摘要信息]
图6：成功添加许可证后，仓库主页的显示效果

---

二-B：【最佳实践】在创建新仓库时就添加许可证

这是最推荐的方式，它能确保你的项目从诞生之初就拥有明确的开源身份。

步骤

1. 在创建新仓库的页面（github.com/new），填写完仓库名称等基本信息后，向下滚动。
2. 找到“Add a license”（添加许可证）的选项。
3. 点击 Choose a license 下拉框。
4. 从列表中选择 MIT License。
5. 点击页面底部的 Create repository 按钮。

[图片：创建新仓库页面，高亮显示“Add a license”下拉框并已选择MIT License]
图7：在创建仓库时直接选择许可证

完成！ 你的新仓库在创建之初就会自动包含一个LICENSE文件，无需任何后续操作。

---

三、总结：为何添加许可证至关重要？

状态	法律含义	对他人的影响	GitHub显示
没有LICENSE文件	保留所有权利 (All Rights Reserved)	无法合法地使用、复制、修改、分发	无许可证信息
有MIT LICENSE文件	授予了广泛的权利	可以自由使用、修改、分发，只需保留原始版权声明	清晰显示MIT License

为你的开源项目添加一个许可证，是一个微小但至关重要的举动。它不仅保护了你作为作者的权利，更重要的是，它赋予了社区自由使用和贡献你代码的权利，这才是开源精神真正的核心。现在，就去为你的项目选择一个合适的“通行证”吧！

---

核心前提：不选择任何许可证 ≠ 自由使用！
根据国际版权法，如果您的代码没有明确的许可证，它就处于默认的“保留所有权利”（All Rights Reserved）状态。这意味着，从法律上讲，任何人都不能合法地使用、复制、修改或分发您的代码。因此，为您的项目选择一个许可证，是其能够被称为“开源”的第一步。

一、开源许可证的三大阵营

我们可以将绝大多数开源许可证划分为三大类，它们的“开放”程度逐级递减，而“约束”程度逐级递增。

1. 宽松许可证 (Permissive Licenses)

   • 核心理念：“基本上，你想用我的代码做什么都行，只要保留我的版权声明就行。你不需要将你的代码也开源。”
   • 代表：MIT, Apache 2.0, BSD

2. 弱许可证 (Weak Copyleft Licenses)

   • 核心理念：“你可以使用我的代码，但如果你修改了我的代码，那么被你修改的这部分也必须用相同的许可证开源。但是，你项目中其他部分的代码（只是调用了我的代码，而没有修改）可以不开源。”
   • 代表：Mozilla Public License 2.0 (MPL 2.0), GNU Lesser General Public License (LGPL)

3. 强许可证 (Strong Copyleft Licenses)

   • 核心理念：“任何使用了我的代码的软件，其整个项目都必须使用相同的许可证开源。你的就是我的，我的还是我的，我们一起开源。”
   • 代表：GNU General Public License (GPL)

---

二、主流许可证的详细对比

下面这个表格将帮助您直观地理解它们之间的关键差异。

特性	MIT License	Apache License 2.0	BSD License (2-Clause)	MPL 2.0 (Mozilla)	LGPL v3 (Lesser GPL)	GPL v3 (GNU)
阵营	宽松	宽松	宽松	弱Copyleft	弱Copyleft	强Copyleft
商业使用	✅ 允许	✅ 允许	✅ 允许	✅ 允许	✅ 允许	✅ 允许
修改代码	✅ 允许	✅ 允许	✅ 允许	✅ 允许	✅ 允许	✅ 允许
分发代码	✅ 允许	✅ 允许	✅ 允许	✅ 允许	✅ 允许	✅ 允许
用作闭源软件	✅ 允许	✅ 允许	✅ 允许	✅ 允许 (仅调用)	✅ 允许 (仅链接)	❌ 不允许
必须包含版权声明	✅ 是	✅ 是	✅ 是	✅ 是	✅ 是	✅ 是
必须声明代码修改	❌ 否	✅ 是	❌ 否	✅ 是	✅ 是	✅ 是
专利授权	❌ 无明确规定	✅ 明确授予	❌ 无明确规定	✅ 明确授予	✅ 明确授予	✅ 明确授予
Copyleft范围	无	无	无	每个文件	每个库/组件	整个程序
简洁度	极简	复杂	极简	中等	复杂	非常复杂

关键差异点解读：

• 专利授权 (Patent Grant)：这是Apache 2.0和GPLv3相对于MIT/BSD的一大优势。它们明确规定，贡献者授予用户一个永久的、全球性的、免费的专利许可。这可以有效防止某些贡献者未来利用专利来起诉该软件的用户，因此深受大公司青睐。
• 声明代码修改 (State Changes)：Apache 2.0和所有Copyleft许可证都要求，如果你修改了代码，必须在文件中明确说明你做了哪些修改。MIT和BSD则没有这个要求。
• Copyleft范围（“传染性”）：这是区分弱Copyleft和强Copyleft的核心。
  • MPL 2.0：传染性以“文件”为单位。你修改了A文件，那么A文件必须继续用MPL 2.0开源。但你项目中未修改的B文件可以保持闭源。
  • LGPL：传染性以“库”为单位。你修改了某个LGPL库，该库必须继续LGPL。但你只是动态链接（调用）这个库的上层应用程序，可以保持闭源。
  • GPL：传染性覆盖“整个程序”。只要你的项目中用到了任何GPL的代码，哪怕只是很小一部分，你的整个项目都必须以GPL开源。

---

总结：

1. “我只想让代码传播得越广越好，怎么用都行”

   • 首选：MIT License。这是GitHub上最受欢迎的许可证。它极度简单，几乎没有任何限制，最大化了代码的复用可能性。如果你不知道选什么，选MIT通常不会错。
   • 备选：Apache License 2.0。如果你希望你的项目在企业环境中更具吸引力，并且想避免潜在的专利纠纷，Apache 2.0是更好的选择。它更“法律完备”。

2. “我希望我的库被广泛使用，但库本身要保持开源”

   • 首选：LGPL v3。专门为库设计的许可证。它允许闭源的商业软件动态链接你的库，这大大增加了库的采用率，同时保证了库本身及其衍生版本始终开源。
   • 备选：MPL 2.0。一个更现代、更清晰的弱Copyleft协议。它以文件为界限，比LGPL更易于理解和遵守，非常适合用于开发可扩展插件或模块化系统。

3. “我信奉纯粹的开源精神，希望我的成果和所有衍生品都回馈社区”

   • 首选：GPL v3。这是“自由软件”运动的基石。它确保了任何基于你项目的工作，都必须以同等的自由度（即开源）分享给所有人。非常适合开发完整的应用程序、操作系统或核心框架。
   • 特别情况：AGPL v3。如果你的项目是一个网络应用或后端服务，GPL v3有一个“漏洞”：公司可以在内部服务器上大量修改和使用你的代码，但只要他们不“分发”这个软件，就不需要开源。AGPL堵住了这个漏洞，它要求通过网络提供服务的用户也必须提供源代码。这是保证时代开源精神的利器。