我的系统包含了GPL软件，就必须开源吗？

Posted 2023-04-13

参考技术A

上篇文章我们介绍了Linux等开源软件使用的开源许可协议GPL，GPL有一项要求是由GPL软件派生出来的软件，如果该软件涉及到分发，则也必须遵守GPL，即需要开源，这被称为GPL的“传染性”。比如我修改了一个GPL程序，那我需要开源我的程序，我拿了GPL中的一段代码，也需要开源我的程序，我用到了一个GPL函数库，也需要开源我的程序。这个问题争议比较多，究竟应该怎么做才能符合GPL的规定，在现实使用中有许多让人拿捏不准的地方，有的有定论，有的没有定论，这篇文章我们只是拿几个问题做简单的讨论。

库函数是程序运行时使用到的一些API集合，例如GNU C 库（GNU C Library，又称glibc）。我们都知道库函数一般都是实现一些底层的、基本的功能，使用库函数既可以提高程序的运行效率，又可以提高编程的质量。但是如果一个库使用的是GPL协议，那你在你的程序中使用这个库，你的程序是不是会被传染？这个问题有不同的看法，自由软件基金会（Free Software Foundation，FSF）认为这种情况下确实会使你的程序被传染，你只要链接到了GPL库，那你的整个程序在分发的时候必须开源，否则就不能使用该库。

但是我们说过库函数都是一些基本的、底层的功能，如果使用了GPL协议，就会限制了专利程序使用该库函数，对自由软件的推广是不利的，于是又提出了一种 GNU宽松通用公共许可证 （GNU Lesser General Public License，简称： LGPL ），这种许可证主要是用在函数库上的，最大的特点是允许非自由软件链接到库而不必受到传染，比如GUN C库就是用的LGPL协议。

所以在自由软件基金会的观点里，链接到GPL库的程序必须开源，而链接到LGPL库的程序不必开源。

在FSF的说明中对软件聚合在一起使用有单独的说明，主要就是分清这些程序到底是独立的程序还是同一个程序的不同部分。例如，FSF认为可以从程序之间通信的机制（exec、pipes、rpc、共享地址空间的函数调用，等等）和通信的语义（交换了什么样的信息）来判断。

如果你的程序全都是打包在一个可执行文件里的，那肯定就是一个程序，整个程序都要遵守GPL。而程序之间如果是以pipes、sockets和命令行参数来通信的话，那这些程序基本可以判定是独立的程序，不同的程序可以遵守不同的协议。如果程序之间交换的数据结构特别的复杂，语义非常密切，一般也可以认定这是同一个程序。

但是FSF也强调，判断聚合在一起的程序是单独的还是同一个大程序，最终是一个法律问题，应该由法官来判定。

Linux使用的是GPL协议，那移植于Linux上的程序是否受GPL传染？其实你的程序是否受GPL影响和你底层的操作系统是没有关系的，主要还是看我们上面说的第一条，你使用的库是用的什么协议，如果你的程序完全没有用到Linux上的库或者只用到LGPL库，那自然不受传染，如果用到了GPL库，那就会受到GPL传染。按FSF的说法，用GPL发布的库一般都是一些非常专业的库，在其他的平台上是没有的，既然专属Linux，那开源也没有什么问题。

mysql使用双协议授权，其社区版用的是GPLv2，以Java开发为例，程序和数据库之间通信方式是socket，按本文前面的说法我们的Java程序不会受MySQL传染，不必遵守GPL。但有一个问题，我们用的驱动都是Oracle以GPL协议提供的，我们确实把这些驱动都打进了一个包里，那我们的程序就被这个驱动给传染了，在你卖你的程序的时候，必须把源代码同时给对方。

但现实我们在使用中很少听说使用MySQL还要开源程序源代码的，网上搜了一下，各种观点都有，大多数人基本都忽视这个问题了，而那些认为不必开源的理由我认为看似最有说服力的一个是“Java提供了JDBC，Mysql驱动只是对JDBC API的一种实现，是可以被替代的，不是程序的必要部分”。

关于这个问题，网上的分歧还是挺大的，到现在也没个权威的说法，也没有相应的法律判例，当然如果你的程序不是用来分发的也就根本不用去纠结这个问题了，说到底，这是一个法律问题。

GPL传染的特性保证了程序的开源，保证了大多数程序员使用程序的自由，但同时也限制了一些专利程序使用GPL软件的自由。如果是在一些非常明确的情况下，我们应该遵守GPL去开源相应的程序，但如果是一些有歧义的情况下被人要求开源代码，那就交给法官去判断吧。

开源软件许可证 严格性比较

开源软件许可证 严格性比较

宽松：MIT > BSD > Apache > LGPL > GPL > AGPL
1、MIT：MIT许可证之名源自麻省理工学院（Massachusetts Institute of Technology, MIT）
只有一点限制：所有应用必须包含版权声明和许可声明(自己修改后的声明)

2、BSD
可以自由的使用，修改源代码，也可以将修改后的代码作为开源或者专有软件再发布。
强调重代码作者的著作权
只有两点限制：1、只需要把原来的BSD协议(不可以改)包含进来 2、不可以用开源代码的作者/机构名字和原来产品的名字做市场推广
任意控制，商用首选

3、Apache
Apache Licence是著名的非盈利开源组织Apache采用的协议。该协议和BSD类似，同样鼓励代码共享和尊重原作者的著作权，同样允许代码修改，再发布（作为开源或商业软件）
需要给代码的用户一份Apache Licence 如果你修改了代码，需要在被修改的文件中说明。 在延伸的代码中（修改和有源代码衍生的代码中）需要带有原来代码中的协议，商标，专利声明和其他原来作者规定需要包含的说明。 如果再发布的产品中包含一个Notice文件，则在Notice文件中需要带有Apache Licence。你可以在Notice中增加自己的许可，但不可以表现为对Apache Licence构成更改。
Apache Licence也是对商业应用友好的许可。使用者也可以在需要的时候修改代码来满足需要并作为开源或商业产品发布/销售。

4、LGPL：宽松公共许可证（Lesser General Public License）或库通用公共许可证（Library General Public License）
始终开放源代码
GPL宽松版：如果您的程序对遵循 LGPL 的软件进行任何连接、调用而不是包含，则允许封闭源代码。

5、GPL：通用性公开许可证(General Public License，简称GPL)
规定：始终开放源代码，使用GPL协议程序的程序必须遵循GPL协议，即A包含或调用B，如果B为GPL协议，则A发布时也必须为GPL协议（强调A发布）
适用：GPL是针对传统的软件分发模式的商业模式(以微软为代表)
缺点：互联网公司（网络服务）则不受到影响（因为不发布软件就不用受到GPL限制，所以AGPL来了）

6、AGPL：Affero 通用公共许可协议
始终开放源代码，向社区提交修改
GPL加强版：最典型的例子就是一个Web应用程序如果使用了AGPL许可证，那么运行这个Web应用程序或其派生作品供他人访问时就需要以AGPL发布其源代码，除非购买商业许可。