是佛心還是惡霸條例，了解GPL開源(Open Source)許可證的風險與感染性

各位讀者還記得小編之前為大家介紹過的開源 license嗎?

開源(Open Source)介紹：在開源時代的興起下，如何透過License共享並保有權益

當我們在享受先人為我們開荒墾拓原始碼的同時，中間其實蘊含了許多鮮為人知的陷阱，這當中一但誤觸可是容易讓你跳到尼羅河都洗不淨的，而這樣的看似好心的GPL就蘊含了許多強制開源的風險性，在介紹前先為大家複習一下GPL的定義：

簡單來說GPL就是一個看似好用，但實為惡霸的病毒License， 在享受開源的同時，必須把「開源信條」變成像「感恩Seafood」「讚嘆師傅」的口號去供奉。去信仰這樣的擴散規則，而GPL並像病毒一般具有感染效應 (viral effect)，會將你開發的專案裡中，使用到的其他元件，也一併感染成為 GPL 的授權狀態。(「感恩Seafood」「讚嘆師傅」 )

而這種具備擴散性的授權特性，雖然遵守 Stallman 對於軟體自由自由開放的理念，卻剝奪了 GPL 程式碼取用者，對於衍生作品授權方式的選擇與自由。

在這樣褒貶參半的授權中， 對於單純下載程式做免費使用的人來說，相當屬於受到歡迎，而若你對認同自由軟體理念的開發者，當然也是樂於遵守。但對於那些想使用GPL的程式碼卻因為各種原因不願開源後續衍生或插件開發的人來說(就像失傳的祖傳秘方)，就必須去另外尋找合適的GPL原件來替代，更別提使用祖傳秘方販售的人，往往被勒令開放的同時，必須對販售策略上進行調整，來保障自己的開發權益。

而使用GPL並且開放的依據是甚麼呢?根據當初GPL 草擬者 Richard Stallman 所表示的「最嚴格標準」，就是原始碼內儘管是一行使用 GPL 程式碼，也是可以構成開放的條件的，儘管真實因為一行程式碼開放的案例目前仍未看見，但這也代表著在甚麼樣的惡霸意義呢?

把程式碼用食譜來想像，今天你上網使用了一個公開的食譜，其中加入的醬油卻是自家代代相傳的私釀祖傳手工醬油，而在吃到你食譜的客人，發現這醬油的鮮味可以把整道菜提升到另外一個層次裡，於是打著GPL的旗幟要求你一定要開放祖傳醬油的配方。

光是這樣想就覺得夠惡霸的了，難道我只要依循了開放的準則，就沒辦法保有我開發的所有隱私嗎?而祖傳祕方早已失傳多年，我又要怎麼開放給你呢?或是想像當中你握有的原始碼裡，其中有部分的 Plug-in 竟然沒有開放，而在你衍生利用的同時，卻被其他第三方要求強制公開所有的 Plug-in ，我的老天鵝阿，這樣的漏洞是怎樣發生的呢

當然上有行規，下有對策，聰明如我們當然也想到了應對的作法

如果李嚴也是一個遵循GPL的崇好者，在他端出炸鳳尾蝦的同時跟你說，嘿小當家，要不要試試我的祖傳醬汁呢?這可以讓鳳尾蝦提升到另外一個世界的口感呢?而李嚴也真的端出了那道醬汁讓你一起食用，而最後你想要使用GPL的手段讓李嚴公開他的醬汁秘方時，李嚴卻回覆你：不不，這個醬汁當初並不是跟這道菜一起研發使用的，我可是有在菜單後面備註說明了呢?所以我的醬汁可以享受不開源的依據來不公開唷，而這也是業界常說到的「分開散佈」原則。

將具有GPL的程式碼和非GPL的程式碼分開做散佈，讓這些你不願意公開的程式碼，透過附加元件(或是插件)的方式，透過動態連結「Dynamic link」來做執行，也就是當你安裝GPL程式碼的時候，跳出一個視窗詢問是否安裝插件，並且寫上說明文字表示插件非GPL，但使用插件時可以讓你原本的程式執行得更為順暢，一旦你經確認執行了安裝後，這樣就完成所謂分開散佈的原則，因為你同意了使用非GPL的插件，而這個插件也在說明文字中表示為非GPL授權，而其中把插件和主程式結合的動作是「你」自己執行的，就像我們常見的"是否下載並安裝附加元件"，所以結合插件與主程式，使插件變成GPL授權的執行者是「你」，我當然就沒有開源插件的義務囉。

當然用文字的說明上來檢視是相當簡單的，但一旦你沒有認真確認那些文字內容，就把這樣的程式及插件再利用並散佈，這樣你就必須具備公開插件的責任和義務囉。就像小當家如果在菜單上寫李嚴鳳尾蝦佐醬汁，那公開醬汁的祕方，也就是你必須要擔當的責任了。

這樣的例子很常在具備GPL授權而著名的WordPress上發生，儘管其中有許多的插件與版型都必須預先付費才可以下載取得商業授權，這些工具雖然多數為開發者參考其中的架構開發而成，但程式碼的部份、絕大部分都是開發者自己另外開發，並沒有直接編輯或引用原來 CMS 的程式碼，而且執行安裝插件及版型的執行者為使用者本身，當然這些工具本身就可不具備GPL以及開源的條件亦算合理， 也就如同 Linux Torvalds在Linux內核的版權文件COPYING中最前面多了一段敘述，來保證了Linux內核的商業用途不被GPL給強制授權，並允許 Linux 上單純執行的應用程式，可以不採用 GPLv2 授權的例子，而Android把GNU/Linux中的系統庫glibc換為libc( Google改寫優化的FreeBSDBionic庫，屬於BSD，故可以選擇性開源)，來規避GPL的感染性

這些範例給軟體開發者多了許多自我解釋的空間，也就是面對開源與否的權利中，如何善用聲明做解釋，並且保護自己的權益不售損

「在一般自由開源軟體世界的實務上、如果權利人已經就個別情況做了額外的清楚解釋，那原則上便是以尊重權利人解釋範圍的方式來進行。」

所以儘管成事在天，但解釋在人，只有熟讀條例及實際執行範例，才不會在未來專案的開發及散佈上吃了悶虧，而其中分開散佈的確也是保有自己智慧財產權的一大妙招，但記住，在規避的同時也要想清楚如何有效的遵守GPL規範也是當等重要的一件事情，在2006年德國軟體工程師 Welte提告台灣友訊 (D-Link)違反GPL條款，成為了世界首宗GPL判決案例(因販售 NAS 產品的驅動程式中，採用了 GPL 授權程式，但因未附上無擔保聲明，也沒有提供使用者驅動程式原始碼以及 GPL 文字全文，最後D-link吃上敗訴的官司)

切記，在保護開源的同時，也必須善用聲明及分開散佈原則來做好自我保護，才能確保自己的權益不被開源的洪流給淹沒。

最後，如果你喜歡我們的文章，別忘了到我們的FB粉絲團按讚喔!!