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

上篇文章我们介绍了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去开源相应的程序，但如果是一些有歧义的情况下被人要求开源代码，那就交给法官去判断吧。

不必呀，比如第三方的mp3解码库和nvdia驱动就都有不开源的版本，大部分linux发行版都会在你下载，安装这部分必源软件时给予你提示，那为啥要用闭源软件呢？要么找不到开源的，要么开源的性能比不上闭源的

---