進度條

避免無謂的商業授權費,搞懂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

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