進度條

避免無謂的商業授權費,搞懂LGPL與GPL的不同

與QT有關係的軟體都需要龐大的授權費?其實在大多的商業運用是不用的喔!

作者: Vincent Ke 更新日期:

近年來電腦效能的進步與記憶體裝置價格下降的關係,工程師喜好的程式語言配置變化了很多,很多時候不再以程式效能為第一優先考量,並加上網際網路的發展迅速,到現在 IOT (物聯網)的開發趨勢。

 

所以例如 JavaScript、Python、Ruby 等逐漸成為開發的主流,並且也將從網路後端Server程式跨到桌面與手機應用程式。Python 、Ruby、Go 語言都已經有與老牌跨平台應用程式 QT 互動的函式庫可以使用(可以把 QT 想成是 C++ 做成的一個圖形化介面函式庫)。而 JavaScript 則是有 Github 所開發的 Electron 作為新興的跨平台桌面程式解決方案之一。

 

不過在使用這些優秀的解決方案之前,請先注意他們的授權 Licence 條約喔!就算是開源 Open Source 也不代表可以無償使用。

 

 

我們這邊以 Python 為例,Python 可以透過 PyQt 或是 PySide 做到QT函式庫的呼叫,很容易就可以幫 Python 應用程式安裝撰寫使用者介面。

 

 

不過 PyQt 與 PySide 是不同的開發團隊所組成的,所以在選擇上,就有相當大的差別,其中 PyQt 是商業授權以及 GPL 的並行,也就是要馬你付授權金(550美元/1個開發者),要馬就是你使用後就要套用 GPL 全部開源。

 

 

天阿! GPL 這個病毒條例又出現啦!

但別慌,你還可以選擇使用 LGPL 的 PySide 

 

 

校正小編補充:

其實 PyQt 是學以前的QT,在 QT 4.7版以前,也是複合型的授權。
你可以使用免費的 GPL,或者是”每月“459美元的授權費(每個月付14,000新台幣,連微軟都沒那麼誇張。)
但是在 QT 4.7版以後改成了現在的 LGPL 授權(因為 GPL 感染性,所以不是所有人都可以改,只有撰寫的那個團隊才行)
整體來說鬆綁了很多,也有商業上的價值了。


PyQt 並不是 QT 官方團隊所開發的,所以沒有義務跟隨,
但 PySide 是 QT 官方團隊開發的,所以 PySide 現在也是 LGPL 授權。
但其實他們之間的支援度與支援方式是有差的(畢竟是一個有收錢的獨立開發團隊)


至於 LGPL 是怎樣的授權,就還請繼續往下看
 

 


首先小編來前情提要一下,GNU General Public License 也就是 GNU 通用公眾授權條款(GNU General Public License,可簡稱 GNU GPL、GPL),保障了所有用戶端的自由使用權利,包含共享、修改及合法的自由運用,簡單來說若是 GPL,你可以自由地使用如複製、修改、發布服務等,並且沒有流量及數量上的限制,這樣自由的權利是以「copyleft」為依據,如開發的產品中使用copyleft 條款之後,該產品可允許使用者自由使用、散布、改作,但依據了copyleft 條款,一但你使用了跟 GPL 有關的套件做開發,你也被必須要求改作後的衍生作品,也需要以同等的授權方式釋出以回饋社群,以著作權法來創造出創作自由,使用 GPL 最著名的就是 Linux V2。

 


所以簡單來說,當你使用了 GPL 的東西來做為你開發程式上的一部分時,你就已經被納入了開源的共產社區了,儘管這是開源的好意,但這樣的善意要我們照單全收似乎也太過嚴苛了吧,而在 V3 版的 GPL,還可以讓你賭氣要求選擇是否可一併保障該作品未來版本的"更版"及修正,一律冠上 GPL。

 

 

我開源,我未來的子孫都要開源,這真是有點過分啊!!

 

 

 

 

但好險,有問題就會有因應的解法,現在有一個解法已經誕生了,也就是 GNU Lesser General Public License ,LGPL。

 

 

由於 GPL 過於嚴格,也間接影響到了程式碼的被採用率,畢竟開發的目的就是為了營利,相信這對很多人來說都是共通的目標,而這個 LGPL,從字面上來看其實就是所謂的鬆綁版的GPL啦,目前也出到了第三版了,儘管這個 License 仍受到 「copyleft」的規範,但定義上來看即為「較寬鬆的 GPL」

 

 

LGPL 是自由軟體基金會 (Free Software Foundation, FSF) 針對函式庫類別程式所特別撰寫出來的自由軟體授權條款,這是因為函式庫本身的性質有關,多半句有函式庫類型的程式,本身就很容易透過連結(Link)的方式來做呼叫以及取用,並提供各種類別的儲存資訊及運算結果給其他軟體或是原件給利用,但若是這樣的函式庫本身是屬於 GPL 的規範的話,也意味著這樣只要使用到函式庫的程式也必須使用 GPL 來做 License

 

 

但這樣本身也太過嚴格了吧,一來函式庫本身並不屬於獨立程式,二來這樣的定義太過狹隘,以後誰還敢碰有GPL的函式庫阿..

 

所以 GNU 考量到函式庫本身的應用推廣,為避免讓大家退避三舍,就以 GPL 為範本修改出 LGPL,來規定若是用了 LGPL,單純的函式庫乎叫本身並不需要被 LGPL 的拘束性給規範,來做為推廣函式庫的一大利器,也讓這樣更符合開源及應用的初衷,但當然 GPL 畢竟仍然屬於 Licence 的一種,本身也包含著所謂的"必須" 或 "但是"囉!

 

先來為各位解釋一下"必須"吧:若今天使用者參考了 LGPL License 的軟體(包含函式庫),進行任何改動、和/或再次開發並予以發佈,則您的產品必須一樣被感染上了 LGPL 協定,並且開源,並於 LGPL 協議內提供修正處的文字檔,來提示各位我們這一次引用了什麼,修改了什麼,並且仍然無私的奉獻給大家,所以 LGPL 還是具備著所為的病毒性和擴散性。

 

 

但是如果僅是針對 LGPL 的軟體進行任何調用、連接而非包含、修改後再利用,則可以不需開源,也就是可以封閉並做商業利用啦。這個"可是"不僅僅是針對了函式庫,本身其實也對 LGPL 內的應用方式做出了鬆綁。也就是所謂的「 LGPL 約束性不包含在僅透過定式介面或流程呼叫具 LGPL 性質的函式庫」,因為通常透過這種方式來呼叫的動態連結裏面,並不會涉及到被呼叫的程式碼。

 

所以將 LGPL 的產品思考到商業模式上是比 GPL 較為可行的,例如 ffmpeg 是一個同時以 GPL 和 LGPL 發佈專案,其中內容結合多媒體框架與播放解碼器 (codec) ,在基礎功能部分以 LGPL 發佈,但其中有一部份"最佳化部分播放"功能則以 GPL 發佈。這也意味著若是你僅參考基礎功能的函式庫,那你不開源並做販售是沒有問題的

 

 

正因為 LGPL 是鬆版的 GPL,所以你可以從嚴認定,讓 LGPL 轉變成 GPL 再向外散佈是可行的,但 GPL 可就不能從寬認定為 LGPL 囉, 例如你引用了 LGPL 的函式庫,但是卻加以修正,把函式庫這種動態連結的引用特性給移除的話(就是把 LGPL 的函式庫修正為非函式庫的特性),那就只能把他從寬鬆的LGPL 升等成 GPL 了。

 

而在文章一開始提到的 Qt,為了使用者的開源性及應用性做考量,現在也支援GPLv2、GPLv3 及 LGPLv3 等各種授權(當然也跟他被 Nokia 收購脫離不了瓜葛),而這樣的好處就是可以保持 Qt 在各式平台上的可用性,開源社區的發展性以及商業領域的可用性,畢竟 GPL 對商業模式有很大的受限。但最後謹記,不管開源和營利與否,最後 License 的使用一定都要從元件及程式間的依賴性來做討論。

 

 


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

Medium vincent

Vincent Ke

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