上篇文章我們介紹了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的一種實現，是可以被替代的，不是程序的必要部分”。

關於這個問題，網上的分歧還是挺大的，到現在也沒個權威的說法，也沒有相應的法律判例，當然如果你的程序不是用來分發的也就根本不用去糾結這個問題了，說到底，這是一個法律問題。

結語

GPL傳染的特性保證了程序的開源，保證了大多數程序員使用程序的自由，但同時也限制了一些專利程序使用GPL軟件的自由。如果是在一些非常明確的情況下，我們應該遵守GPL去開源相應的程序，但如果是一些有歧義的情況下被人要求開源代碼，那就交給法官去判斷吧。