登入  |  English
感謝您對「自由軟體鑄造場」的支持與愛護,十多年來「自由軟體鑄造場」受中央研究院支持,並在資訊科學研究所以及資訊科技創新研究中心執行,現已完成階段性的任務。 原網站預計持續維運至 2021年底,網站內容基本上不會再更動。本網站由 Denny Huang 備份封存。
也紀念我們永遠的朋友 李士傑先生(Shih-Chieh Ilya Li)。
法律專欄 自由軟體專案授權方式的轉換(下):新版本號另以更改後的授權方式釋出

法律源地

本網站法律源地提供相當多自由軟體授權與法律的資訊,歡迎您閱讀這些資訊。

 

自由軟體專案授權方式的轉換(下):新版本號另以更改後的授權方式釋出

本文上篇的文章連接頁面如右:https://www.openfoundry.org/tw/legal-article-/8195-2010-11-22-18-38-45

【新版釋出、授權更改】

那麼、既然我們無法用事後撤銷的方式來改變已經釋出的自由軟體授權狀態,當日後專案有授權轉換的需求產生時,究竟應該透過怎麼樣的做法來達到授權變更的目的呢?目前實務上推行的方式,簡單來說就是八個字:「新版釋出、授權更改」。

顧名思義,「新版釋出、授權更改」指的是利用專案釋出新版本號的軟體時,為此新版本號選用更改後的授權條款,這樣的作法並不會影響原釋出版本的授權狀態,但透過新版本號釋出的軟體程式碼,就可以適用轉換過後的新授權方式來讓人使用。舉前例來說、程式 A 到第 1.0 版為止都是採用 GPL 第 2 版 (GPL-2.0) 來授權 ,經修改之後 A 專案可以特別標注為第 1.1 版,此時若是 1.1 版的修改者本身就是 A 專案的著作權利人,或是得到 A 專案原著作權利人的同意,那就可以將新版本號的 1.1 版改用 GPL-2.0 以外的條款來授權散布,例如改採 LGPL-2.1 或是 BSD 類別的授權條款,或者是乾脆將新版本號轉為採用 GPL-2.0 與商業條款並行的雙重授權模式 (dual-licensing model) 也可以(註一)。並且、A 專案在 1.0 版與 1.1 版之間的差異可大可小,有時甚至兩個版本號的程式碼完全相同亦沒有問題,因為此種作法的重點就是在於讓使用者清楚辨識同一個自由軟體專案的不同版本號,並明白了解該專案不同的版本號就代表了「不同的授權方式」,從而日後運用上不會產生授權混淆的錯誤。

【利用新版本號釋出專案程式碼的實益】

透過「新版釋出、授權更改」方式,已經釋出的自由軟體專案程式碼,就可以事後完成授權轉換,但運作此種方式最重要的前提要件就是,新授權方式的轉換者本身必須是該專案全部程式碼的合法權利人,或至少已經得到權利人明示允許對此專案進行授權轉換,因為這種方式實質上其實是讓 1.0 版與 1.1 版新舊版本同時散布的「雙重授權模式」,願意以原授權方式得到程式原始碼的使用者,可以持續以舊授權模式利用該專案的 1.0 版,而接受新授權方式的使用者,也可以改用新的授權模式使用 A 專案最新的 1.1 版本。當然、此時很多自由軟體專案的開發者就會問,以「新版釋出、授權更改」的方式進行專案授權方式的轉換究竟有何實益?因為形式上似乎只是平行增加了 A 專案的授權方式,而若是使用者堅持延用舊的授權方式來使用該專案的程式碼,似乎也並沒有有效辦法能誘導使用者改用新的授權方式來使用這個專案?其實不然、前面雖然提到 1.0 版本的程式碼可以與轉換過授權的 1.1 版本完全相同,但實務上的狀況是,該 A 專案的權利人多會擴充或刪減該程式的功能後,再以 1.1 版本的方式釋出,在這種狀況之下,這些新編寫進來的最新功能,使用者就只能透過 1.1 版本的新授權方式才能取得,所以雖然 1.0 版本的授權方式並沒有辦法被權利人事後撤銷,但隨著 A 專案不斷的被增裨與改寫,多數使用者都會接受以新版本號的授權方式來使用該專案後續完成的程式碼,實質上來說、這就是一種自然演繹的引導方式。

【利用新版本號變更條款文字的實例】

其實、以版本號的變更來宣告授權內容的變更,在自由軟體授權領域裡幾乎已形成群體共識。舉 GNU 計畫另一款重要的授權條款 LGPL 為例,許多人都知道就版本別來看,LGPL 近年有 LGPL2、LGPL-2.1 與 LGPL-3.0 三個版本,但是大概很少人知道 LGPL 第 2 版的內容與 2.1 版的內容幾近完全相同,不同之處僅在於條款全名有所更改,並稍微調整了一些介係詞與相關的技術名詞(註二)。既然新舊版本的差異那麼的小,那麼為何世上會有文字內容幾近完全相同的 LGPL2 與 LGPL-2.1 版本的授權條款呢?其實這個條款版本號的修改,是 GNU 計畫的創立人 Richard Stallman 為了要將 LGPL 條款的全名,由最初的 "GNU Library General Public License",改寫為 "GNU Lesser General Public License",因為 LGPL 最初的全名 "GNU Library General Public License",會讓許多的程式開發者誤以為只要是函式庫程式就只能採用 LGPL 來授權,而不能採用 GPL 這種更為開放的授權方式,對於 Richard Stallman 來說,這與他初始撰立 LGPL 的預期有所衝突(註三),所以為了將授權條款名稱裡的 "Library" 改為 "Lesser",這世上就多了與 LGPL2 條款內容幾近完全相同的 LGPL-2.1,這就是一個透過版本號的變異來宣告授權文字有所變化的實例,從這個例子我們可以看到,實務上自由軟體授權條款內容變異時的嚴縝性,以及版本號在自由軟體授權領域裡的靈活運用。

【以 Qt 為實例進行授權轉換的說明】

「新版釋出、授權更改」的實例不在少數,目前因併購而歸屬於 Nokia 旗下的 Qt 就是一個相當著名的例子。Qt 是一個跨平台的圖形界面開發工具,最早由一家挪威公司 Trolltech 所開發並擁有著作權利,初期 Trolltech 透過自行撰寫的 Q Public License (QPL) 與商業條款來雙重授權這個專案。不過因為 QPL 與 GPL-2.0 在授權上並不相容,但自由軟體領域裡以 GPL-2.0 授權的元件卻愈來愈多,所以為了調和 Qt 與這些 GPL-2.0 授權元件的相容性,2005 年在發布 Qt 第 4 版 (Qt/Windows 4) 的時候,Trolltech 捨棄 QPL 改採 GPL-2.0,自此以後 Qt 改為 GPL-2.0/商業條款併行的雙重授權模式,後來隨著 2007 年 GPL-3.0 定稿的發布,Qt 也透過程式改版的動作,將新版本號的 Qt 改為 GPL-3.0/商業條款併行授權。不過這樣的 GPL-3.0/商業雙重授權模式維持不久,因為之後 Nokia 公司收購了 Trolltech,並在 2009 年釋出 Qt 第 4.5 版時,加入了 LGPL-2.1 授權條款為另一個使用者可選擇的授權模式(註四),自此 Qt 的授權狀態變為 GPL-3.0/LGPL-2.1/商業三重授權模式(註五)。回顧過去十年,Qt 所適用的自由軟體授權條款一變再變,不過這些改變都是在程式改版升級的時候加以進行,並且僅僅適用於新版與未來版本,過去已經發布的舊版 Qt 軟體,在授權內容上不會有任何的改變,這是一個「新版釋出、授權更改」的鮮活實例,同時、也是一個不因授權轉換而影響前版軟體授權狀態的最佳例證。

【跳脫傳統框架以建立長久良性的授權模式】

自由軟體所採用的是一種不同於傳統的授權模式,若是不多做論理直接採用既有的法律架構來處理相關問題的話,將有可能產生悖離現實運作的結論,進而引發許多難以解決的棘手問題。而在面對自由軟體專案授權方式轉換這一個問題的時候,鑑於目前並沒有相關的司法判決,因此自由軟體的授權特性與軟體社群的運作習慣,就顯得格外的具有參考重要性。如同之前所評論的,自由軟體授權條款具有授權給公眾利用後不間斷散布的特性,再加上經過十多年的實務運作,全球絕大多數的軟體使用者已經對於自由軟體的授權模式,產生不會向後撤銷的信賴共識,因此筆者透過此篇文章分享這個議題的論理觀點:自由軟體專案的授權態樣原則上不可嗣後撤銷,否則將會造成難以解決的全球性軟體授權混亂,而若是已釋出的自由軟體專案想要改變授權方式的話,則可以採用「新版釋出、授權更改」的方式,透過最新版本號的軟體釋出,逐步地改變專案程式碼在未來的授權方式。而也唯有在這樣的運作機制之下,全球的軟體開發者可以在互信互助的基礎下,共同維持良性的自由軟體開發循環模式,讓已經在全球發展近二十多年的自由軟體共同開發制度,繼續穩定而長久地運作下去。


註一:雙重模式的說明可以參見:林誠夏,自由軟體的商業應用模式(下)-雙重授權篇,自由軟體鑄造場電子報第 83 期,https://www.openfoundry.org/tw/legal-article-/1056-2010-07-15-10-36-02;林誠夏,20070130-Dual license-雙重授權模式的美麗與哀愁,https://lucien.cc/?p=62
註二:LGPL 第 2 與 2.1 版的英文全文請參見:https://www.gnu.org/licenses/old-licenses/old-licenses.html#LGPL
註三:從 Richard Stallman 的角度出發,他希望世上所有的軟體專案都能夠以 GPL 授權條款釋出散布,但因為函式庫的程式多以連結的方式供其他程式讀取資訊,若是全以 GPL 的方式釋出的話,那授權拘束性的涵攝範圍就會非常的大,這會導致許多自由軟體專案的程式開發者怯步而避免使用 GPL 來釋出其專案,所以退而求其次的提供授權拘束性範圍較窄的 LGPL 來讓這些專案開發者選用,但仍然期盼認同其理念的專案開發者,能適時的以 GPL 授權條款來釋出其所撰寫的函式庫程式。
註四:在 Nokia 公佈這項消息的新聞稿中,第三段第一句的文字就明確表示,Qt 不但繼續提供商業授權版本,所有過去版本的授權狀態也不會有任何的改變,該段原文:"Qt 4.5 will also be available under commercial licensing terms, while licensing for previous versions of Qt remains unchanged.",新聞稿的原文連結請參照:https://qt.nokia.com/about/news/lgpl-license-option-added-to-qt
註五:Qt 官網:https://qt.nokia.com/。QPL 英文全文內容請見:https://www.opensource.org/licenses/qtpl.php/。Qt 過往的授權歷史複雜,本文僅擷取重點加以說明,進一步資訊可以參見:https://en.wikipedia.org/wiki/Qt_%28framework%29#History。目前三重授權的介紹與分析可以參考:https://blog.linux.org.tw/~jserv/archives/002085.html

您也許有興趣閱讀以下文章:




自由軟體鑄造場電子報 : 第 164 期 自由軟體專案授權方式的轉換(下):新版本號另以更改後的授權方式釋出

分類: 法律專欄