开源协议选型指南

一、开源协议简介

在进行软件项目开发时，开发者需要为自己的项目选择合适的开源协议。开源协议（Open Source License）用于规定软件的使用、修改、分发以及再发布等行为的权限和义务，从而明确项目作者与使用者之间的权利边界。

不同的开源协议对软件的传播和使用有着不同的要求。有些协议允许开发者自由地将代码集成到商业项目中，仅要求保留原作者的版权声明；而有些协议则要求修改后的代码在分发时继续保持开源，以确保开源软件及其衍生作品能够持续自由地被使用和改进。

根据对衍生作品开源要求的不同，常见的开源协议通常可以分为两大类：

• 宽松型协议（Permissive License）：允许用户自由使用、修改和分发代码，通常仅要求保留原作者的版权声明和许可证文本，代表协议有 MIT、BSD 和 Apache License 2.0 等。
• Copyleft 型协议（Copyleft License）：在允许用户使用、修改和分发代码的同时，要求修改后的代码在分发时继续采用相同或兼容的开源协议进行发布，代表协议有 GPL、AGPL 和 LGPL 等。

二、各类开源协议介绍

接下来针对Github上常见的几种开源协议分别介绍其特点及适用场景。下图为Github中，在每个项目创建LICENSE文件的时候出现的开源协议选项。

根据各个协议的特点，绘制对应的开源协议分支图

宽松型 / 公共领域类

• WTFPL 协议
  极度宽松，几乎没有限制，允许任何使用、修改、分发和闭源商业行为，不要求保留署名或版权声明。适合个人小工具和实验项目。
• Unlicense 协议
  尽量放弃版权并进入公共领域，如果法律不允许放弃版权，则授予无限制使用许可。适合软件项目，允许闭源和商业使用。
• CC0 协议
  由 Creative Commons 组织制定，放弃所有可放弃的版权和邻接权利，法律文本完善，适用于数据集、文档、图片、音频等内容资源，也可用于软件。

宽松型协议

• MIT 协议
  保留版权声明和许可证文本即可，允许修改、闭源和商业使用，是最常用的宽松开源协议之一。

  反例：现在有一个采用 MIT 协议的 JSON 解析库，你将其代码集成到自己的商业项目中，并删除了原作者的版权声明和 MIT 协议文件后对外发布。这种行为就违反了 MIT 协议，因为 MIT 要求保留原作者的版权声明和许可证文本。

• BSD 3-Clause 协议
  与 MIT 类似，但禁止使用原作者或组织名称为衍生产品进行宣传或背书，避免误导或损害原作者声誉。

  反例：现在有一个采用 BSD 3-Clause 协议的网络通信库，你在产品宣传页面上写道：本产品由该开源项目作者官方推荐，但实际上并未获得作者授权。这种行为违反了 BSD 3-Clause 的非背书条款。

• Apache 2.0 协议
  宽松协议，允许闭源和商业使用，额外提供专利授权，同时包含专利报复条款：如果用户起诉项目专利，获得的专利许可会自动终止。

  反例：现在有一个采用 Apache 2.0 协议的消息中间件项目，你在发布产品时删除了 NOTICE 文件和许可证信息，同时使用该项目后又以专利侵权为由起诉该项目。这时，项目授予你的专利许可会自动终止。

Copyleft 协议

• MPL 2.0 协议
  文件级 Copyleft，修改过的 MPL 文件必须开源，新增文件可采用其他协议发布，适合混合闭源与开源开发场景。

  反例：现在有一个采用 MPL 2.0 协议的浏览器组件，你修改了其中的 render.cpp 文件，然后将修改后的版本集成到商业软件中发布，但拒绝公开修改后的 render.cpp 源码，这种行为违反了 MPL 2.0 协议。如果有一个function.cpp文件为你自己创建并编写，那么这个文件可以以任意的协议开源或者闭源。

• LGPL 协议
  库级 Copyleft，允许闭源程序链接该库，但修改库本身必须开源，适用于软件库和组件。

• GPL协议
  强 Copyleft，修改或衍生作品必须开源发布，保证开源生态传播和自由使用，适合强调自由传播的项目。

  反例：现在有一个采用 GPL 协议的开源项目，你在其基础上进行了修改，并将修改后的程序打包出售，但拒绝向用户提供对应源码，这种行为违反了GPL协议。如果对其进行了修改并发布给用户，需要按照 GPL 要求提供完整源码。

• AGPL协议
  基于 GPL 增加网络服务条款，即使仅通过网络向用户提供服务，也必须提供源码，适用于 SaaS 和网络服务类项目。

  反例：现在有一个采用 AGPL 协议的在线论坛系统，修改后部署到服务器供用户访问，但没有向用户提供修改后的源码，将违反AGPL协议，必须在网页中提供源码下载地址。