雖著網際網路的進一步發展，近年來雲端運算成為一鼓新興的潮流，無論是大型的商業公司或小型的資訊服務業者，乃至於個人工作室，都乘著這鼓潮流，嘗試開發網路應用程式或提供相關的商業服務。與一般的軟體開發專案一樣，在開發網路應用程式或線上服務平台（以下統稱這些應用程式與服務平台的開發專案為「雲端應用專案」）的時候，也可能面對部份專案內容無法對外提供程式源碼 (Source Code) 的情況，例如雲端應用專案中某一部份的程式碼，因為受到第三方保密協議的拘束，所以不能對外提供源碼與相關資訊。這樣的專案若仍想要利用自由開源軟體元件來開發的話，那麼選擇哪些條款授權的元件，才不會造成未來應用時產生必須提供程式源碼的衝突，將是開發過程的一項重點。因此，本文將針對常見的自由開源授權條款（註一），說明相關的義務規定，據此建議雲端應用專案可以選擇哪些條款授權的元件，以避免無法提供源碼的專案產生授權義務上的衝突。

【義務規定寬鬆的 BSD 類條款所授權的元件為首選】

BSD 類的授權條款包括了 BSD、MIT 與 Apache-2.0 等，這類條款授權範圍廣大，義務規定寬鬆而有彈性，並不硬性要求使用者在散布程式的同時必須提供源碼，而是交由使用者自行決定，即使是散布修改過的元件也是一樣，因此雲端應用專案的開發者可以優先選擇利用這類條款授權的元件。

【透過散布程式來啟動提供源碼義務的授權條款為次要選項】

其次，GPL-2.0、GPL-3.0、LGPL-2.1、LGPL-3.0、MPL-1.1、MPL-2.0、EPL-1.0 與 CDDL-1.0 這八份條款授權的元件，也是可以選擇的另外一種類別。這類授權條款都具有「授權拘束性（註二）」，原則上會拘束元件修改版本的授權方式，也就是修改後的衍生程式必須採用相同條款來授權，無法採用其他條款授權，例如元件原本採用 GPL-2.0 授權，修改後的版本也因此必須採用 GPL-2.0 授權，而當修改版本隨著軟體專案被散布給後手的時候，依照這些授權條款的規定，散布者必須要提供程式源碼給後手，假如修改版本包含了本文首段所提到的保密協議程式碼的話，那麼將這些程式源碼提供給後手就違反了保密協議，因此這些條款的授權拘束性就與無法提供源碼的保密協議產生衝突（註三）。

但是這樣的授權拘束性原則上卻不會與雲端應用專案產生衝突，因為授權拘束性實際發揮效力的時間點，是在使用者散布程式碼的時候，也就是當使用者散布元件或者修改版本的時候，才有義務要提供源碼，反之，沒有散布行為的話提供源碼的義務將不會被啟動，使用者因此沒有義務一定要釋出程式源碼。由於雲端應用專案原則上都是透過網路提供服務，專案程式碼均在雲端服務提供者的伺服器上執行，並非散布到服務使用者的電腦或裝置中執行，專案程式碼沒有被散布出來，所以透過雲端應用專案來提供服務者，在此狀態下就沒有義務一定要釋出專案程式相關的衍生源碼。

不過在實際應用時，有些雲端應用專案會有部份程式碼被下載到服務使用者端的電腦或裝置中，這樣就產生了程式碼被散布的事實，而若是被散布程式碼的授權條款屬於本段所提及這八份條款的話，雲端服務提供者仍然可能因此負有提供源碼的義務，必須將被散布部份的程式源碼提供給予服務使用者（註四）。

所以若雲端應用專案在實際應用上僅單純地透過網路提供程式服務，所有程式碼仍在伺服器上執行，而因此讓服務使用者不需要下載任何程式碼，那麼利用這八份條款授權的元件來開發專案，是不會讓服務提供者負有提供源碼的義務。但若不能達到上述的狀態，仍然散布了此八份條款授權的元件，則這些被散布元件的程式源碼，便仍必須得進一步提供出來。

【透過網路互動即可能啟動提供源碼義務的 AGPL 系列條款】

利用自由開源軟體元件開發雲端應用專案最需要注意的是 AGPL 系列的授權條款，因為 AGPL 不但具有授權拘束性，還要求透過網路提供「修改版本 (modified version)」程式功能服務的時候必須提供程式源碼，即使這時候並沒有任何程式碼在應用過程中被散布出去也一樣。

AGPL 系列條款均是修改自 GPL 而來，AGPL-1.0 修改自 GPL-2.0，而 AGPL-3.0 則是修改自 GPL-3.0，修改的初衷是要補充 GPL 所沒有涵蓋到的網路應用程式服務提供者 (Application Service Provider, ASP) 的利用行為，因為如上段所說明過的，網路應用程式服務提供者若是透過網路單純提供 GPL 程式的應用服務，由於程式碼沒有散布出去，服務提供者也不需要將源碼提供出去。針對這樣的利用行為，AGPL 規定即使在程式碼沒有被散布的情況下，只要有透過網路提供程式服務給客戶利用的行為，提供源碼的義務也因此啟動，服務提供者必須進一步將程式源碼提供給客戶。

關於 AGPL 這個特殊的規定，有兩項要件需要被特別注意（註五）：
 
(1) AGPL 程式碼是被修改過的 ("...if you modify the Program...")，若 AGPL 程式沒有被修改，那麼服務提供者即沒有提供源碼的義務；

(2) 服務使用者透過網路與 AGPL 程式修改版本互動（"...all users interacting with it remotely through a computer network..."，註六），也就是透過網路來利用 AGPL 程式修改版本的功能。

依照這樣的要件規定，利用 AGPL 授權的元件來架構網站、提供線上文書處理功能、讓使用者在網路上收發電子郵件或者查詢資料等，都有非常高的機率必須要將這些程式的衍生源碼提供給予網路服務使用者。因此若是雲端應用專案在實際應用上雖然沒有散布程式碼，但卻讓服務使用者可以利用到 AGPL 授權元件的功能，若評估後認為全面的程式源碼提供機制不符合預設期待的話，建議應慎重考量是否改用其他條款授權的元件來執行相同的功能，以避免授權衝突的狀況產生。

【遵守授權條款的其他義務】

本文只針對提供源碼這一項授權義務來加以分析、說明，但是自由開源授權條款所包含的義務規定不單單只有提供源碼這一項，還可能包括保留著作權聲明、保留免責聲明、提供授權條款全文、標示修改資訊等等。尤其保留各項標示資訊是相當基礎的義務，幾乎所有的自由開源授權條款都有這樣的義務規定，例如：當雲端應用專案利用到 BSD 類條款授權元件的時候，雖然網站服務提供者不負有提供源碼的義務，但若仍然有散布程式碼情況發生的話，就必須要重建元件中原本所附帶的各項標示資訊或聲明，讓服務使用者可以瀏覽到這些內容，以符合 BSD 類條款所規定的義務；此外，GPL-3.0、LGPL-3.0 與 AGPL-3.0 這三份條款也特別要求使用者，無論修改原程式與否，只要有使用到這些條款授權元件的事實，該統合專案在使用上就必須將相關聲明標示出來。（註七）。

【結語】

由本文以上的介紹可以了解到，在沒有程式碼被散布的情況下，雲端應用專案開發者在選擇自由開源軟體元件時，雖然必須特別注意 AGPL 系列授權條款，但卻有著相當大的彈性範圍來選擇授權條款與元件，而若是在應用上將會有程式碼被散布出去的話，除了 AGPL 系列條款外，還必須注意其他具有授權拘束性的條款是否與專案的應用狀況相符合，若是專案並無法提供任何程式源碼給與專案使用者的話，那麼就應該改採用 BSD 類條款的元件。因此在判斷可以利用哪些自由開源授權條款與元件時，只要先釐清雲端應用專案未來實際運作的狀況，以及是否會有程式被散布出去的狀況，然後就可以根據這些實際狀況，來選擇授權內容適合的自由開源軟體元件來應用，有效地減少授權衝突發生的機率。
 
------

註一：常見授權條款分類表：https://www.openfoundry.org/tw/foss-license-category；而關於授權條款各類別特性的介紹，請見：自由開源軟體授權條款的三分法：https://www.openfoundry.org/tw/legal-column-list/105-2010-07-15-10-42-58。

註二：關於授權拘束性的說明以及其對於衍生程式的影響，請見：林誠夏，GPL 條款對於衍生程式的判定標準與其授權拘束性的擴散範圍（上），https://www.openfoundry.org/tw/legal-column-list/8446-the-license-inheritance-bounds-of-gnu-gpl-01。

註三：這八份條款所包含的授權拘束性強弱不同，其中以 GPL-2.0、GPL-3.0 的授權拘束性較強，LGPL-2.1、LGPL-3.0、MPL-1.1、MPL-2.0、EPL-1.0 與 CDDL-1.0 等六份條款的授權拘束性較弱。後六份條款雖然規定，原則上修改版本必須繼續採用原條款授權，但若僅是透過既成機制與 LGPL 函式庫元件溝通互動，或者單一檔案或模組中的程式碼均為使用者自行撰寫，那麼非 LGPL 函式庫的其他部份、使用者自行撰寫的單一檔案或模組等部份，是可以例外地採用其他條款來授權。進一步的比較說明請參考：自由開源軟體授權條款的三分法：https://www.openfoundry.org/tw/legal-column-list/105-2010-07-15-10-42-58。

註四：承接註三的說明，由於這八份條款的授權拘束性強弱不同，因而影響到必須提供出來的程式源碼範圍也會有所不一樣，所以實際上必須提供哪些部份的程式源碼給予服務使用者，要看所牽涉的授權條款規定與個別雲端應用專案的狀況而定。

註五：囿於文章篇幅，本文無法詳細介紹 AGPL 的授權規定，若想進一步了解 AGPL 系列條款的內容，可以參考：葛冬梅，因應網路時代與雲端應用而生的 AGPL-3.0 授權條款，https://www.openfoundry.org/tw/legal-column-list/8809-introduction-to-agpl3。

註六：本段內文乃是擷取 AGPL-3.0 第 13 條第 1 項的原文文字。AGPL-1.0 相對應的規定在第 2 條第 1 項第 d) 款中，文字大同小異："If the Program as you received it is intended to interact with users through a computer network..."。

註七：關於各授權條款的義務規定，可以先參考自由軟體鑄造場網站上各條款的基本說明：https://www.openfoundry.org/tw/licenses。若欲進一步了解這些義務的詳細內容，可以至法律專欄中點選相關的文章閱讀：https://www.openfoundry.org/tw/legal-column-list，或者也可以寄發電子郵件至自由軟體鑄造場詢問。

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

• 商業利用自由開源軟體之商標須知 - 2013-06-25
• 善用管理流程以妥善利用自由開源軟體加入產品開發 - 2012-02-20