自由開源軟體授權條款的互惠性 - 採用自由開源軟體之法制指引

授權條款的「互惠」（Reciprocity）要求（又稱 Copyleft 分享義務），是指修改原作並加以散布時，應將衍生程式以程式源碼，或其他適合對程式進行修改、改作的相類格式進行釋出的義務。

(二) 互惠義務的觸發（Trigger）

互惠義務將於符合下述全部要件後啟動：

1. 採用以 Copyleft 授權條款所授權的程式碼；

2. 使用者/開發者對開源碼加以修改、改作，而產生修改物（Modification）或衍生程式（Derivative Work）；

3. 該修改物或衍生程式的程式碼，經「散布」

（Distributed）的方式，傳遞（Conveyed）或傳送

（Propagate）予他人。

以上三大要件皆實踐之後，散布該修改物或衍生程式者，就必須應後手使用者的要求，同時或嗣後提供該修改物或衍生程式的程式源碼。然而，倘未對於具有 Copyleft 授權特性的軟體元件進行修改或改作，而僅是將其原始內容與其他具運作獨立性的軟體元件一起散布，則此合併散布的行為，並不會使得隨同 Copyleft 元件一起散布的其他程式，皆必須遵守 Copyleft 性質條款的分享義務。

(三) 互惠要求的程度

圖 2：不同種類授權條款之互惠要求高低與感染力強弱

資料來源：本研究繪製

互惠義務依其要求程度，可分為高、中、低三種，說明如下：

1. 高度互惠要求

高度互惠要求的授權條款，又稱為限制型

（Restrictive）條款，內含較強的 Copyleft 要求。

高度互惠要求為體現極度分享的精神，會要求修改程式部份亦應釋出程式源碼，這些程式源碼包括程式的安裝資訊（Installation Information）、編譯腳本

（Compiling Script），或其他相類形式得供後手進行改作的程式資訊，在某些個案上，甚至與程式源碼相連結，在運作上較難切割的相關元件，有時也會被列在釋出源碼的範圍之內。此種高度互惠要求的授權類型，以 GPL 與 AGPL 為代表。GPL 類型被認為是最具有拘束性/感染性的條款，能將其他程式「感染」成自由開源軟體，因而被認為最「嚴格」、最為貫徹開放精神的授權條款。

2. 中度互惠要求

中度互惠要求的授權條款，又稱為限制混合型

（Restrictive-hybrid）的授權條款，對於 Copyleft 的要求較為緩和，此類型以 LGPL、MPL、CDDL，

與 EPL 為代表。

此種條款雖有互惠規定，但僅於某些例外情況下才需互惠。此類型以 MPL（Mozilla Public License）為代表。MPL 擬訂之初，參考了 GPL 等授權條款，

而保有一定的彈性，允許自由開源軟體元件與私有

軟體元件結合在同一個軟體專案中進行運作，而不必然影響不同元件之間的授權狀態；其中度的互惠要求，是發生在使用者對 MPL 授權元件之利用，

若構成對元件本身進行「修改」或「改作」行為，

才需依 MPL 之授權方式，釋出修改與衍生部分的程式源碼。

3. 低度互惠要求

低度互惠要求的授權條款，又稱為寬鬆型

（Permissive）條款，該類型以 MIT、BSD，與 APL 為代表。

寬鬆型的授權條款不含互惠的規定，目的在於降低採用自由開源軟體的限制，進而增加使用動機。此類型以 BSD 為代表，其對於被授權人的限制最少，被授權人僅需於再散布相關程式時保留原專案作者的著作權聲明以及免責聲明；被授權人對於原程式之修改與改作亦享有極大自由，在對其修改或改作之後，再散布時可以自由選擇符合散布者偏好的授權模式，甚至將其改採商業授權的方式進行後續運用。

(四) 互惠要求與風險

授權條款之互惠義務一旦被觸發，使用者/開發者必須在散布行為裡，同時或嗣後提供修改物（Modification）

或衍生程式（Derivative Work）的程式源碼，並採用相同或相容之授權條款來提供這些程式源碼；不然，使用者/

開發者對原程式的使用方式，可能便涉及授權條款的違反

與著作權利的侵犯。因此，使用者/開發者對應授權條款之類別，可以約略得知其預期用途之潛在風險。

表 1：授權條款類別的風險程度 高互惠性

授權條款

中互惠性 授權條款

低互惠性 授權條款

散布衍生程式 高度潛在風險中度潛在風險低度潛在風險

不散布衍生程式 中度潛在風險低度潛在風險極低度潛在風險資料來源：本研究整理

由於互惠程度愈高的授權條款其授權義務性規定愈容易被觸發，對於使用者/開發者來說，如何在第一時間從授權條款的互惠程度、採用行為與預期用途，辨識所預計採用之自由開源軟體專案的風險（以互惠義務為主），

就成為一個重要的工作步驟（請見下圖）。接續風險層級辨識後，使用者/開發者必須繼續檢視組織對於自由開源軟體的採用政策，進一步判斷預期使用的自由開源軟體授權條款類型所屬風險層級，是否為組織所能接受的範圍內，或可能有任何例外排除的狀況。

(五) 互惠義務是否被觸發之要素 例如：BSD, MIT, APL

圖 3：自由開源軟體風險辨識–以互惠義務為主資料來源：本研究繪製

1. 「修改」（Modified）與「衍生」（Derived）

對程式源碼簡要的腳本變更與參數置換，一般會被視為不具著作權改作意涵的修改行為

（Modification），多數論者認為這樣的修改行為，

並不會變動該軟體專案的權利狀態，故輕簡修改物，其修改前與修改後，在多數狀況可視為同一著作物；而「衍生行為」，多數論者認為可回歸著作權法的預設，參考各國著作權法對軟體改作產生衍生程式的標準，但由於實務上亦不具權威性的解釋判例，故目前產業實務上，多參考自由軟體基金會

（FSF）和 Linus Torvalds（Linux Kernel 的開發者）

的解釋與判斷標準，或直接引據所使用的自由開源軟體專案其著作權利人，已對外公布發表之衍生行為之判定標準。

下圖為軟體開發者將限制型授權條款之自由開源軟體元件，與其專案加以含括（Incorporate）的幾種重要情境（情境 A 至 E）。在這些情況下，都「可能」產生「衍生程式」。承上所述，如實務上缺乏通說的判斷標準，亦無特定專案權利人發布的引導文件，並對所欲使用的自由開源軟體專案互惠義務存有疑慮，則建議使用者/開發者應就實務上的利用狀況，蒐集更多具體相關資訊，並依此尋求專業法律意見的協助。此部份的進階說明，請參見「肆、

採用自由開源軟體之風險辨識與管控二、依常見的條款用語詞彙辨識風險（一）衍生程式」以獲取更多資訊。

情境A：增加 200 行程式源碼以擴展原程式的功能

情境B：將所開發之軟體與自由開源授權的功能模組（靜態函式庫 - Static Library）加以編譯（Compiled）並製成單一可執行的軟體程式。

情境C：將所開發之私有軟體與自由開源授權的即時操作型函式庫（Runtime Library），結合在同一個編譯器與安裝程式中進行互動（Interact）。

圖 4：採用自由開源軟體元件進行開發之情境

資料來源：澳洲政府機關自由開源軟體指引（2011）

情境D：與情境 C 類似，將所開發之私有軟體與自由開源授權的軟體程式，結合在同一個編譯器與安裝程式中進行互動。結合狀態為第一個程式可直接透過系統層級的執行命令，呼叫（Invoke）

第二個程式所提供的功能，此為高度緊密與層級化的結合模式。

情境E：與情境 A 類似，此情境基本上是採用自由開源軟體授權方案為基底，在修改與調校之後，用之在雲端式的線上服務方案，雖然是透過網路進行線上服務，未必會觸發提供程式源碼的義務，但原則上服務系統本身，會被視為自由開源軟體專案的衍生程式。

2. 「散布」（Distribute）與「傳遞」（Convey/Propagate）

（以 GPL 為例）

目前 GPL 數個版本對於「散布」與「傳遞」的定義略有不同，但基本上，這就是一個啟動 GPL 軟體散布者擔負程式源碼提供義務的先行行為。

GPL-2.0 使用的詞彙為「散布」（Distribute），一般認為此一詞彙與著作權法所用的「散布」

（Distribute）為等價的詞語，指的是程式碼確實已透過載具（Storage Medium）進行傳散的狀態。而後 GPL-3.0 則再將此詞彙轉為非法律慣式用語的

「傳遞」（Convey/Propagate），這是因為當前對於軟體程式的使用基礎，非必然是傳統上因買賣而產生的重製與散布關係，其亦有可能是租用或其他非定式法律關係，故 GPL-3.0 以口語化的「傳遞」來取代著作權法定式的「散布」，以明示只要程式碼的傳遞，是讓使用者取得實質掌握程式碼運作的地位，則傳遞者便已擔負程式源碼的提供義務，無論此一傳遞行為的基礎法律關係為何。進一步的說明，請參見 GNU 網站（www.gnu.org）的常見問題清單（Frequently Asked Questions），以獲取更多資訊。

依據 GPL 的規定，該使用者/開發者傳遞或散布其修改、改作部分的程式碼給他人，使用者/開發者就應履行下列相關義務：

（1）此一經修改或改作過後的程式源碼，在釋出目的碼時，必須同時採用 GPL 授權條款的方式進行程式源碼的提供；

（2）明確告知後手哪些檔案的程式源碼已經被修改的事實；

（3）如果不欲隨著程式目的碼同時提供程式源碼，則應另行提供一紙正式的紙本或電子文件（Written Offer），此後，持有文件之人，便可在三年的期間內，洽 GPL 程式目的碼的商業散布者，在支付工本費用之後索取相對應的程式源碼。

八、授權條款間的相容性

在文檔中採用自由開源軟體之法制指引 (頁 24-34)