开源许可协议比较及应用实例

简介

使用开源代码可以帮助提高软件开发效率并节省成本，但是如果不当使用开源代码，也可能给个人及公司会带来知识产权方面的法律风险，不仅要花费大量的费用，有时候甚至需要公开自有的商业代码，“赔了夫人又折兵”，给个人和公司造成极大的损失，所以在商业软件使用开源代码前认真评估开源代码所携带的许可证显得尤为重要。

截至2019年6月，国际开源组织OSI(Open Source Initiative)批准的许可证超过80种，其中被广泛使用的许可证包括以下8种：

• Apache License 2.0 (Apache-2.0)
• 3-clause BSD license (BSD-3-Clause)
• 2-clause BSD license (BSD-2-Clause)
• GNU General Public License (GPL)
• GNU Lesser General Public License (LGPL)
• MIT license (MIT)
• Mozilla Public License 2.0 (MPL-2.0)
• Eclipse Public License version 2.0

根据使用条件的不同，开源许可证分为两大类，即Permissive许可证和Copyleft许可证。

Permissive许可证

Permissive License（宽松式许可证）允许用户不经许可可以随意复制、修改和发布，并且分发时可以使用不同的许可证，用户可以在修改代码后选择闭源，常见的Apache、BSD、MIT属于Permissive许可证。

BSD (Berkerley Software Distribution)

BSD许可证给予用户在使用开源代码方面很大的自由，分为2-Clause(两条款)和3-Clause(三条款)两类，需要遵守以下规则：

1. 如果分发的软件包含源代码，则必须在源代码中保留原始的BSD许可证声明。
2. 如果分发的软件仅包含二进制程序，则必须在文档或版权说明中保留原始的BSD许可证声明。
3. 未经许可，不得使用原始作者或机构的名字为软件做市场推广。（仅3-Clause需要遵守）

使用BSD许可证的应用案例包括：Chromium，Django，FreeBSD，Nginx等。

Apache-2.0

Apache Licence是著名的非盈利开源组织Apache采用的协议，需要遵守以下规则：

1. 必须在源代码中保留原始的Apache许可证声明。
2. 如果用户修改了源代码，需要在被修改的文件中说明。
3. 在衍生产品中，必须保留原来代码中的版权、专利、商标及作者规定的其他需要包含的说明等信息。
4. 如果在分发的软件中包含Notice文件，则需要在Notice文件中包含Apache许可证声明。

使用Apache 2.0许可证的应用案例包括：Apache家族系列产品，如Hadoop, OpenOffice, Spark，SVN, 以及Swift、Kubernetes、Android Open Source Project (AOSP)等。

MIT (Massachusetts Institute of Technology)

和BSD-2-Clause类似，即需要遵守以下规则：

1. 如果分发的软件包含源代码，则必须在源代码中保留原始的MIT许可证声明。
2. 如果分发的软件仅包含二进制程序，则必须在文档或版权说明中保留原始的MIT许可证声明。

使用MIT许可证的应用案例包括：Bootstrap, jQuery, Node.js, Rails等。

Copyleft许可证

Copyright（版权） 的意思是未经许可，用户无权复制和使用。Copyleft License（反版权许可证） 作为Copyright的反义词，意为未经许可，用户也可以随意复制、修改和发布，但要求分发者必须使用相同的许可证发布修改后的衍生作品，以保证衍生作品也能被其他人自由使用，常见的AGPL, GPL, LGPL, MPL属于Copyleft许可证。

GPL 2.0

只要软件中引用及修改了GPL代码或者链接了GPL类库，整个软件就就必须遵循GPL，不仅需要公开所有源码，并且允许他人可以自由地复制和分发。

使用GPLv2许可证的应用案例包括：Linux内核、MySQL等。

GPL 3.0

GPLv3包含了明确的专利许可以及添加了对数字版权管理和加密签名的限制，不仅要求用户公开源码，还要求公布相关硬件及必要的安装信息。

GPLv3能与更多的许可证兼容，例如Apache 2.0，但这个兼容是单向的，即GPLv3许可证的项目中可以包含Apache 2.0的开源代码，但是Apache许可证的项目不能包含GPLv3的开源代码。值得注意的是，GPLv3与GPLv2却并不兼容，即一个项目中不能同时包含GPLv2和GPLv3的代码，但是，如果软件以GPL “v2或更高版本”许可证发布，则与GPLv3兼容。

使用GPLv3许可证的应用案例包括：GCC，Emacs等。

AGPL

AGPL是对GPL的补充，如果使用了AGPL代码的软件是一个网络应用，那么这个软件的所有源码和修改代码也必须开源，除非购买了该AGPL代码的商业授权。

使用AGPL许可证的应用案例包括：BerkeleyDB，MongoDB (2018年10月前发布的版本)，Wiki.js等。

LGPL

和GPL相比，LGPL限制更少，是一个主要为类库使用设计的开源协议，需要遵守以下规则：

1. 如果软件通过动态链接的方式使用LGPL类库，则该软件不需要开源。
2. 如果软件通过静态链接的方式使用LGPL类库，则软件作者必须提供程序的二进制目标文件（不需要提供源代码），以便用户有机会更新LGPL类库并重新链接到该程序。
3. 如果修改了LGPL的源码或者衍生了新的代码，则所有修改后及衍生的代码也必须遵循LGPL许可证。

使用LGPL许可证的应用案例包括：7-Zip，GLib，uClibc等。

MPL (Mozilla Public License)

MPL License由Mozilla基金会开发并维护，介于BSD（衍生代码可以闭源）和GPL（衍生代码必须以GPL方式开源）之间，最新发布的2.0版以更简洁和更好的兼容其他协议为目标，鼓励企业和开源社区为开发核心软件做更多贡献。使用MPL源码需要遵守以下规则：

1. 如果修改了MPL的源码或者衍生了新的代码，并且以源代码方式发布的文件，则所有修改后及衍生的代码也必须遵循MPL许可证。
2. 如果用户自有的源码通过专用接口访问MPL的源码及类库，则包含专用接口的代码必须遵循MPL许可证，用户自有源码不必遵循MPL许可证。
3. 用户获得MPL代码中的专利许可，但是不能使用其原始商标。

使用MPL许可证的应用案例包括：Mozilla Firefox, Mozilla Thunderbird, Apache Flex, LibreOffice等。

EPL (Eclipse Public License)

EPL License由Eclipse基金会开发并维护，在CPL基础上删除了专利相关诉讼的限制条款。EPL比GPL许可证更为宽松，并且与GPL并不兼容。使用EPL源码需要遵守以下规则：

1. 如果修改了EPL的源码或者衍生了新的代码，并且以源代码方式分发，则所有修改后及衍生的代码也必须遵循EPL许可证。
2. 如果软件以二进制目标文件的形式分发，则需要声明可以根据请求向其他用户提供源代码。
3. 用户获得EPL代码中的专利许可。

使用EPL许可证的应用主要为Eclipse基金会名下的软件，如著名的集成开发工具 - Eclipse。

应用实例

MariaDB

MariaDB是目前最受关注的MySQL数据库衍生版，由开源社区开发和维护，诞生于Oracle收购MySQL后，目标是成为MySQL的替代品。

MariaDB的服务端使用的是GPL v2许可证，如果软件只是内部使用，并且没有被包含在对外发布的产品中，这种情况不被视为分发，可以自由使用；如果软件用于对外发布，使用了服务端的GPL代码或者通过链接的方式使用了客户端的GPL动态库，或者软件与MariaDB数据库强绑定，即在没有安装MariaDB数据库的情况下，软件无法运行或者只能使用非常少的功能，该软件也必须遵循GPL许可协议；但是如果该软件通过第三方独立框架访问数据库，

MariaDB的C/JAVA/ODBC的客户端动态库使用了LGPL许可证，软件也只需遵循LGPL协议，可以自由使用这些动态库，不存在必须开源的问题。

如果软件通过调用非GPL的连接器与MariaDB数据库进行通信，例如：mysqlnd for PHP, ruby-mysql等，软件只需要遵循该连接器所使用的许可证。如果软件通过第三方独立的框架访问数据库，即使框架中使用了包含GPL许可证的模块，例如：ODBC, JDBC, Perl，PHP PDO等，软件本身并不受其影响，不需要遵循GPL许可证。如果发布的软件除了可以访问MariaDB数据库之外，还可以访问其他数据库，即MariaDB在软件中不属于必须项，在这种情况下该软件可以和MariaDB一起自由发布，同样不需要遵循GPL许可证。

如果软件中必须使用数据库服务端的相关代码，又不希望自己的商业代码遵循GPL许可证，可以考虑以下三种方案：

1. 使用类似MIT/BSD许可证的PostGreSQL作为替代产品。
2. 更换为不使用SQL作为查询语言的NoSQL非关系数据库方案，例如：Cassandra (Apache 2.0), Redis (BSD-3-Clause), 或者 CouchDB (Apache 2.0)等。
3. 付费购买带有商业许可证的软件，如MySQL, MongoDB等。

Linux Kernel

Linux内核以GPL v2许可证发行，所以任何Linux内核的衍生产品也必须遵循GPL许可证进行发布。如下图所示的应用实例，我们列出其中违反GPL许可证的使用方法（红线所示）。

​1. 应用程序通过静态或动态链接的方式使用GPL类库，会导致整个应用也必须以GPL许可证方式发布。规避方法是主程序通过LPC或者RPC间接调用GPL库里的接口，或者改用动态链接LGPL类库的方式。
2. 应用程序通过非标准接口直接访问Linux内核的行为，会导致整个应用也必须以GPL许可证方式发布。规避方法是通过Linux 内核提供的标准接口函数访问Linux内核，用户空间的程序及类库的普通系统调用不被视为Linux内核的衍生产品，应用程序不需要遵循GPL许可证。
3. 可加载内核模块（LKM）是用户编写的软件，它与Linux内核紧密绑定，运行在内核地址空间中，Linux内核开发社区认为LKM程序应该遵循GPL许可证。但是不少硬件厂商出于保护商业机密及知识产权的角度出发，在这一点与Linux内核开发社区一直存在争议，硬件厂商一般都会以二进制目标文件的方式单独发布硬件驱动试图规避GPL风险，但是始终存在潜在的法律风险以及开源带来的的商业影响，降低风险的方法就是同样以GPL或者其他与GPL兼容的许可证发布LKM程序，并且不要把那些不希望开源的的私有代码直接链接到LKM程序。

小结

由于GPL严格要求使用了GPL代码或类库的软件产品必须使用GPL协议，所以商业软件最好不要使用GPL许可证的产品。开源许可证既保护代码作者，对他人使用代码产生的风险免责；同时也保护代码使用者，了解使用开源代码的权利及必须履行的义务，规避将来可能的法律风险。

参考文档：

• MariaDB License
• Legal Risks of Open Source – GPL/Linux Loadable Kernel Modules