上篇文章我們介紹了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去開源相應的程序，但如果是壹些有歧義的情況下被人要求開源代碼，那就交給法官去判斷吧。