引用自《开源许可证的一些介绍》

当我们在github、gitee上新建项目的时候，往往不知道到该如何选择一个合适的开源许可证，本文引用gitee上的License介绍对常见的License做一个简单的介绍。

开源许可证

Apache v2 License

Apache Licence是著名的非盈利开源组织Apache采用的协议。该协议和BSD类似，同样鼓励代码共享和尊重原作者的著作权，同样允许代码修改，再发布（作为开源或商业软件）。需要满足的条件也和BSD类似：

  1. 需要给代码的用户一份Apache Licence
  2. 如果你修改了代码，需要再被修改的文件中说明。
  3. 在延伸的代码中（修改和有源代码衍生的代码中）需要带有原来代码中的协议，商标，专利声明和其他原来作者规定需要包含的说明。
  4. 如果再发布的产品中包含一个Notice文件，则在Notice文件中需要带有Apache Licence。你可以在Notice中增加自己的许可，但不可以表现为对Apache Licence构成更改。

Apache Licence也是对商业应用友好的许可。使用者也可以在需要的时候修改代码来满足需要并作为开源或商业产品发布/销售。

MIT License

MIT许可证之名源自麻省理工学院（Massachusetts Institute of Technology, MIT），又称「X条款」（X License）或「X11条款」（X11 License）

MIT内容与三条款BSD许可证（3-clause BSD license）内容颇为近似，但是赋予软体被授权人更大的权利与更少的限制。

被授权人有权利使用、复制、修改、合并、出版发行、散布、再授权及贩售软体及软体的副本。

被授权人可根据程式的需要修改授权条款为适当的内容。

在软件和软件的所有副本中都必须包含版权声明和许可声明。

此授权条款并非属copyleft的自由软体授权条款，允许在自由/开放源码软体或非自由软体（proprietary software）所使用。

此亦为MIT与BSD（The BSD license, 3-clause BSD license）本质上不同处。

MIT条款可与其他授权条款并存。另外，MIT条款也是自由软体基金会（FSF）所认可的自由软体授权条款，与GPL相容。

GPL v2

GPL 是GNU通用公共许可协议(GNU General Public License)的简称，我们很熟悉的 Linux 和 Git 就是采用了 GPL，该协议力图保障你分享和修改某程序全部版本的权利——确保自由软件对其用户来说是自由的。

所谓自由软件，强调自由，而非免费。GNU通用公共许可协议设计用于确保你享有分发自由软件的自由（你可以为此服务收费），确保你可以在需要的时候获得这些软件的源码，确保你可以修改这些软件或者在新的自由软件中复用其中某些片段，并且确保你在这方面享有知情权。

自由权利包括复制、分发和修改。源码是指所有修改作品及生成、安装、运行（对可执行作品而言）目标码所需的源码，包括控制上述行为的脚本，但其中不包括系统库、通用工具。

简而言之，如果你分发自由软件的副本，那么副本中必须包含许可协议和版权声明，并确保接收者能够获取到该副本的源代码及其依赖库的源码。

Artistic License 2.0

Artistic License，又称艺术许可协议（英语：Artistic License），通常指最初的艺术许可协议（1.0版），是一个自由软件授权条款，主要用在官方发布的Perl解释器和大部分CPAN模块的授权。原始的艺术许可协议是由Perl的创始人Larry Wall编写发布的。

BSD 2-Clause license

BSD允许使用者修改和重新发布代码(以其他协议形式)，允许闭源商业发布和销售。

BSD鼓励代码共享的同时，要求尊重代码作者的著作权。

使用BSD协议，需要遵守以下规则：

  1. 再发布的产品中包含源代码，则在源代码中必须带有原来代码中的BSD协议；
  2. 如果再发布的只是二进制类库/软件，则需要在类库/软件的文档那个和版权声明中包含原来代码中的BSD协议。

Affero GPL

是一个广泛被使用的自由软件特许条款，最初由Affero, Inc撰写。此特许条款最新版本为“第3版”（v3），2007年11月发布。Affero 通用公众特许条款是改自GNU通用公众特许条款，并加入额外条款，其目的是为了Copyleft条款应用于在网络上运行的应用程式（如Web应用），从而避免有人以应用服务提供商方式逃避GNU通用公众特许条款。

LGPL v2.1

LGPL是GPL的一个为主要为类库使用设计的开源协议。和GPL要求任何使用/修改/衍生之GPL类库的的软件必须采用GPL协议不同。LGPL允许商业软件通过类库引用(link)方式使用LGPL类库而不需要开源商业软件的代码。这使得采用LGPL协议的开源代码可以被商业软件作为类库引用并发布和销售。

但是如果修改LGPL协议的代码或者衍生，则所有修改的代码，涉及修改部分的额外代码和衍生的代码都必须采用LGPL协议。因此LGPL协议的开源代码很适合作为第三方类库被商业软件引用，但不适合希望以LGPL协议代码为基础，通过修改和衍生的方式做二次开发的商业软件采用。

GPL/LGPL都保障原作者的知识产权，避免有人利用开源代码复制并开发类似的产品

BSD (3-Clause) License

BSD允许使用者修改和重新发布代码(以其他协议形式)，允许闭源商业发布和销售。

BSD鼓励代码共享的同时，要求尊重代码作者的著作权。

使用BSD协议，需要遵守以下规则：

  1. 再发布的产品中包含源代码，则在源代码中必须带有原来代码中的BSD协议；
  2. 如果再发布的只是二进制类库/软件，则需要在类库/软件的文档那个和版权声明中包含原来代码中的BSD协议;
  3. 不可以用开源代码的“作者/机构的名字”或“原来产品的名字”做市场推广。

Eclipse Public License v1.0

EPL允许使用者任意使用、复制、分发、传播、展示、修改以及改后闭源的二次商业发布。

使用EPL协议，需要遵守以下规则：

  1. 当一个代码贡献者将源码的整体或部分再次开源发布的时候,必须继续遵循EPL开源协议来发布,而不能改用其他协议发布.除非你得到了原“源码”拥有者的授权；
  2. EPL协议下,你可以将源码不做任何修改来商业发布.但如果你要发布修改后的源码,或者当你再发布的是二进制文件的时候,你必须声明它的源代码是可以获取的,而且要告知获取方法；
  3. 当你需要将EPL下的源码作为一部分跟其他私有的源码混和着成为一个Project发布的时候,你可以将整个Project/Product以私人的协议发布,但要声明哪一部分代码是EPL下的,而且声明那部分代码继续遵循EPL；
  4. 独立的模块(Separate Module),不需要开源。

LGPL v3

相对于LGPL v2，不仅要求用户公布修改的源代码，还阻止了其他一些私有化的方式，例如：不得将产品内的软件“tivo化”或“锁定”，或者（用行业内的话来说）“安全启动”，也就是说，不得以任何形式阻止用户修改产品内的以 GPL 许可协议发布的软件。

Mozilla Public License Version 2.0

MPL是The Mozilla Public License的简写，是1998年初Netscape的 Mozilla小组为其开源软件项目设计的软件许可证。MPL许可证出现的最重要原因就是，Netscape公司认为GPL许可证没有很好地平衡开发者对 源代码的需求和他们利用源代码获得的利益。同著名的GPL许可证和BSD许可证相比，MPL在许多权利与义务的约定方面与它们相同（因为都是符合OSIA 认定的开源软件许可证）。但是，相比而言MPL还有以下几个显著的不同之处:

  • MPL虽然要求对于经MPL许可证发布的源代码的修改也要以MPL许可证的方式再许可出来，以保证其他人可以在MPL的条款下共享源代码。但是，在MPL 许可证中对“发布”的定义是“以源代码方式发布的文件”，这就意味着MPL允许一个企业在自己已有的源代码库上加一个接口，除了接口程序的源代码以MPL 许可证的形式对外许可外，源代码库中的源代码就可以不用MPL许可证的方式强制对外许可。这些，就为借鉴别人的源代码用做自己商业软件开发的行为留了一个 豁口。
  • MPL许可证第三条第7款中允许被许可人将经过MPL许可证获得的源代码同自己其他类型的代码混合得到自己的软件程序。
  • 对软件专利的态度，MPL许可证不像GPL许可证那样明确表示反对软件专利，但是却明确要求源代码的提供者不能提供已经受专利保护的源代码（除非他本人是 专利权人，并书面向公众免费许可这些源代码），也不能在将这些源代码以开放源代码许可证形式许可后再去申请与这些源代码有关的专利。
  • 对源代码的定义
    而在MPL（1.1版本）许可证中，对源代码的定义是:“源代码指的是对作品进行修改最优先择 取的形式，它包括:所有模块的所有源程序，加上有关的接口的定义，加上控制可执行作品的安装和编译的‘原本’（原文为‘Script’），或者不是与初始 源代码显著不同的源代码就是被源代码贡献者选择的从公共领域可以得到的程序代码。”
  • MPL许可证第3条有专门的一款是关于对源代码修改进行描述的规定，就是要求所有再发布者都得有一个专门的文件就对源代码程序修改的时间和修改的方式有描述。

GPL v3

GPL v3与GPL v2类似。区别在于，不仅要求用户公布修改的源代码，还阻止了其他一些私有化的方式，例如：不得将产品内的软件“tivo化”或“锁定”，或者（用行业内的话来说）“安全启动”，也就是说，不得以任何形式阻止用户修改产品内的以 GPL 许可协议发布的软件。

Public Domain

Public Domain 是人类的一部分作品与一部分知识的总汇，可以包括文章、艺术品、音乐、科学、发明等等。对于领域内的知识财产，任何个人或团体都不具所有权益（所有权益通常由版权或专利体现）。这些知识发明属于公有文化遗产，任何人可以不受限制地使用和加工它们（此处不考虑有关安全、出口等的法律）。创立版权制度的初衷是借由给予创作者一段时期的专有权利作为（经济）刺激以鼓励作者从事创作。当专有权利期间届止，作品便进入公有领域。公有领域的作品由于没有专属权利人，因此公众有权自由使用它们。

选择合适的License

GitHub的使用帮助中对如何授权一个项目有着详细介绍，着重关注一下其推荐的Choose an open source license和The Legal Side of Open Source，按需选择适合自己项目的开源License。