進度條

是佛心還是惡霸條例,了解GPL開源許可證的風險與感染性

曾令D-link身陷麻煩, Android在最初設計就想辦法排除的開源許可證。

作者: Vincent Ke 更新日期:

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

 

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

 

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

 

  GPL保障了所有用戶端的自由使用權利,包含共享、修改及合法的自由運用,你可以自由地使用如複製、修改、發布服務等,並且沒有流量及數量上的限制。


  這樣自由的權利是以「copyleft」為依據,如開發的產品中使用copyleft條款之後,該產品可允許使用者自由使用、散布、改作之外,copyleft條款及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吃上敗訴的官司)

 

 

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

 

校正小編補充:

GPLv2(以下簡稱GPL) 要求的簡單來說就是你在散佈的程式的任何型態時,同時都要附上原始碼。所以無論你是可執行檔、函式庫或是作業系統。 也不管你是用網路下載、USB/光碟抑或是APP Store。只要你有散佈得到你程式的人都應該要能有辦法獲得該程式的完整可編譯原始碼。
所以有以下常見問題的與可能解答(解讀未經過律師, 如有問題以各國法律為準)

1.  Google play可以上傳包含GPL的程式、但Apple 的App Store不行(經典案例 VLC media player),違反Apple的條約(與DRM衝突)

2.  WordPress 是GPL, 所以你的顧客要獲得所有的程式原始碼,即使原本就是函式庫的型態。但是你的顧客安裝WordPress後再下載函式庫合併則不需要,因為該函式庫在合併前並沒有被感染GPL。

3. 利用WordPress架構開發套件並不會讓你的套件自動變成GPL,因為你的套件裡面用到的函式庫並沒有規定一定要使用WordPress。 就算你使用了WordPress的函式,也只是代表你使用了”該名稱“的函式(很多函式庫其實命名都很像,雖然WordPress的函式使用wp_開頭,但沒有表示wp_開頭的函式一定來自WordPress)。

4. 如果你沒有該程式的原始碼卻把它包含進GPL授權的程式散佈,你還是必須要給出該程式的原始碼。所以你一定會違反GPL許可。

5. 違反GPL被告的情況目前(2017)還滿少的,HTC、小米等手機廠常常都被影射違反GPL,  但不能保證不會因此付出法律責任, 各國法律解讀可能不同。

 


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

Medium vincent

Vincent Ke

喜歡把混亂的事情變的簡單 用嘴巴做事其實很可以 但要結合靈活的腦袋思考 就一起來拆解吧