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

近年來電腦效能的進步與記憶體裝置價格下降的關係，工程師喜好的程式語言配置變化了很多，很多時候不再以程式效能為第一優先考量，並加上網際網路的發展迅速，到現在 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 

首先小編來前情提要一下，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 的使用一定都要從元件及程式間的依賴性來做討論。

延伸閱讀：如何避免自製 WordPress 外掛被迫 GPL 授權？顧客購買「付費版」可以免費無限複製不用付授權費嗎？

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