上篇文章我们介绍了Linux等开源软件使用的开源许可协议GPL，GPL有一项要求是由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库的程式不必开源。
GPL软件是否可以和非GPL软件一起用
在FSF的说明中对软件聚合在一起使用有单独的说明，主要就是分清这些程式到底是独立的程式还是同一个程式的不同部分。例如，FSF认为可以从程式之间通讯的机制（exec、pipes、rpc、共享地址空间的函式呼叫，等等）和通讯的语义（交换了什么样的资讯）来判断。如果你的程式全都是打包在一个可执行档案里的，那肯定就是一个程式，整个程式都要遵守GPL。而程式之间如果是以pipes、sockets和命令列引数来通讯的话，那这些程式基本可以判定是独立的程式，不同的程式可以遵守不同的协议。如果程式之间交换的资料结构特别的复杂，语义非常密切，一般也可以认定这是同一个程式。
但是FSF也强调，判断聚合在一起的程式是单独的还是同一个大程式，最终是一个法律问题，应该由法官来判定。
移植到GNU/Linux上的程式是否受GPL影响
Linux使用的是GPL协议，那移植于Linux上的程式是否受GPL传染？其实你的程式是否受GPL影响和你底层的操作系统是没有关系的，主要还是看我们上面说的第一条，你使用的库是用的什么协议，如果你的程式完全没有用到Linux上的库或者只用到LGPL库，那自然不受传染，如果用到了GPL库，那就会受到GPL传染。按FSF的说法，用GPL释出的库一般都是一些非常专业的库，在其他的平台上是没有的，既然专属Linux，那开源也没有什么问题。分发使用MySQL的程式是否需要开源
MySQL使用双协议授权，其社群版用的是GPLv2，以Java开发为例，程式和数据库之间通讯方式是socket，按本文前面的说法我们的Java程式不会受MySQL传染，不必遵守GPL。但有一个问题，我们用的驱动都是Oracle以GPL协议提供的，我们确实把这些驱动都打进了一个包里，那我们的程式就被这个驱动给传染了，在你卖你的程式的时候，必须把源代码同时给对方。但现实我们在使用中很少听说使用MySQL还要开源程式源代码的，网上搜了一下，各种观点都有，大多数人基本都忽视这个问题了，而那些认为不必开源的理由我认为看似最有说服力的一个是“Java提供了JDBC，Mysql驱动只是对JDBC API的一种实现，是可以被替代的，不是程式的必要部分”。
关于这个问题，网上的分歧还是挺大的，到现在也没个权威的说法，也没有相应的法律判例，当然如果你的程式不是用来分发的也就根本不用去纠结这个问题了，说到底，这是一个法律问题。
