依常見的條款詞彙與用語辨識風險 - 採用自由開源軟體之法制指引

本節所提供的資訊，將協助使用者/開發者，認識授權條款常見用語中賦含的資訊。以讓使用者/開發者，在閱讀到授權資訊含有下述語彙時，便能進一步認知到其背後所表彰的意義。

(一) 衍生程式（Work Derived from the Program）

當授權條款中出現「衍生程式」用語，使用者/開發者應注意到未來散布衍生程式時，此授權條款基於互惠要求所律定的回饋範圍。

簡要來說，具互惠要求特性的自由開源軟體授權條款，會要求使用者 /開發者，對基於此授權條款提供之開放源碼進行修改與改作時，後續散布時，必須要將經其修改與改作部份的程式，以程式源碼或其他適宜後手接續修改程式的格式釋出。此種要求是希望使用者/開發者，不要將已內嵌 Copyleft 授權特性的自由開源軟體程式進行私有化，而是一旦散布了修改與改作的成果，便應將此成果分享回饋給已能得到程式目的碼格式的後手使用者。

1. 條款說明

以 GPL-2.0 為例，在 GPL-2.0 條款中要求，當使用者/開發者基於其程式源碼而有所改作（A Work Based on the Program），

進而編撰出衍生程式，後續散布此衍生程式時，便必須延續以 GPL-2.0 授權條款，將程式源碼或其他適宜後手接續修改程式的格式釋出（GPL-2.0, §2 b））。但若部份元件可被合理認定為

「獨立且可區分（Independent and Separate）」的部份，則有機會不受到此項認定的限制（詳後述）。

2. 衍生程式的判定

在 GPL-2.0 條款中，指出修改 GPL-2.0 授權的軟體專案或其任

一部份，會構成「基於此開源程式的作品」（A Work Based on the Program），也就是衍生程式。此時互惠要求與回饋義務的範圍，便及於整個改作的全體（As a Whole）；除非可認定某一部份確實不是衍生自此 GPL-2.0 授權的軟體專案，並且此一部份本身可以被合理認定為獨立（Independent）且可區分（Separate）

的軟體元件。可以說，在 GPL-2.0 條款中，改作行為所影響的衍生範圍，具有一個不斷向外擴大的特性，而由於其所認定應回饋的範圍較大，不少使用者常會因無法精確掌握衍生範圍，

而因而怯步。

為緩和 GPL 寬泛認定互惠要求範圍的現象，嗣後產生了 LGPL 授權條款，LGPL 專用於開放源碼性質的函式庫（Library）軟體。此一授權條款適度的緩和了對於應回饋範圍的認定，在 LGPL-2.1 條款中明示，如果軟體專案僅是透過編譯（Complied）

的方式，將其自行撰寫的元件與 LGPL-2.1 授權的函式庫結合運作，或僅是透過連結（Link）的方式，來呼叫存取 LGPL-2.1 授權函式庫的功能與資訊，那麼這樣的互動模式，除非結合的最終型態是讓整個軟體專案成為一個單一的可執行檔，否則並不會讓軟體專案裡的其他部份，悉被視為 LGPL-2.1 函式庫的衍生程式，故而亦不須釋出此部份的程式源碼（LGPL-2.1, § 5）。LGPL-2.1 條款中指出，上述軟體專案與 LGPL-2.1 函式庫的互動關係，可被定性為單純「利用函式庫的作品」（A Work Use the Library）。

中央研究院–資創中心–自由軟體鑄造場林誠夏先生的文章

「GPL 條款對於衍生程式的判定標準與其授權拘束性的擴散範圍」裡，即是在此理論基礎上進行說明：「許多軟體社群的成員認為其他元件與 GPL 授權元件的互動關係原則上有兩種，一種是基於 GPL 程式改作（Work Based on the Program）

的衍生關係，此時 GPL 授權程式的授權拘束性會擴散至衍生程式；另一種是其他元件單純利用（Work Using the Program）

GPL 程式進行功能展現的獨立關係，而若是判定是獨立關係的話，則 GPL 授權程式的授權拘束性不會擴散到這些獨立元件，

從而這些獨立元件在與 GPL 授權程式合併散布時，僅需要提供與 GPL 程式產生互動關係時的呼叫程序與安裝步驟方面的資訊，而不需要提供此元件所有核心部份的程式源碼」⁶。 (二) 將程式以源碼的形式散布（Distribute the Program in Source Form）

當授權條款中規定程式必須以程式源碼的方式提供時，是希望使用者/開發者，能讓他人以便利的方式近用（Access）該軟體專案相關的程式碼，並保護依某些授權條款釋出的程式源碼，不會在日後被多人接續共工改作的過程中，以迂迴的方法「閉鎖」（Closed）起來。

在 GPL-2.0 條款中指出：軟體著作的程式源碼，指的是程式碼可供修改的最佳模式（The Source Code for a Work Means the Preferred Form of the Work for Making Modifications to it.）（GPL-2.0, § 3）。所以反過來說，如果程式在傳遞時提供的並非程式源碼的形式，則其他取得程式的後手，便不能夠輕易的對此程式進行後續的修改與利用。因此，許多強調互惠要求的自由開源軟體授權條款（GPL、AGPL、

LGPL、MPL、CDDL、EPL），才會律定若使用者，對具 Copyleft 特性的自由開源軟體授權元件進行修改與改作之後，後續的修改物與衍生程式，並非不能使用目的碼或執行檔的格式來進行散布，但當這些目的碼、執行檔的後手使用者，向散布者依其自由開源軟體授權條款提出要求後，目的碼與執行檔的散布者，就必須依照條款事先律定的

6自由軟體鑄造場，「GPL 條款對於衍生程式的判定標準與其授權拘束性的擴散範圍」，

http://www.openfoundry.org/tw/legal-column-list/8446-the-license-inheritance-bounds-of-gnu-gpl-01 （最後瀏覽日:2013/12/1）。

義務性要求，將這些自由開源軟體元件，以及其擴散範圍的程式源碼，提供給先前已得到程式目的碼、執行檔的使用者。

1. 以程式源碼（Source Code）的形式散布

程式源碼簡要來說，就是人類透過資訊工程知識的學習之後，

所能閱讀與了解的程式格式，也是撰寫電腦程式的軟體工程師，後續要就此專案進行修改、改作時，會取用的那份檔案文件。程式源碼可以進一步透過編譯器，編譯（Compile）成電腦可讀的二進制指令，但由於編譯過後的格式，僅適合用來執行程式，而無法讓後續使用者窺探此軟體程式的編撰邏輯，所以採程式源碼的形式散布，是各類自由開源授權條款所認定最佳的散布格式。

2. 以程式源碼以外的其他形式散布

內嵌 Copyleft 特性的自由開源軟體授權條款，會額外律定若以程式源碼以外的形式散布軟體程式，則散布者會被課與額外–

應要求提供程式源碼義務。此類型的自由開源軟體授權條款，

考量到使用者/開發者，以程式源碼以外的形式散布，有時是軟體應用上不可避免的利用態樣，也常常是較常見的態樣，例如，將驅動程式直接編譯到嵌入式裝置裡，或是將應用程式預先安裝到智慧行動裝置一併販售，但僅散布程式目的碼、執行檔的態樣，將可能使他人不容易近用到相關的自由開源軟體源碼，因此此一類型的自由開源軟體授權條款，多會於條款內容增設右列的條款：「軟體專案的目的碼與可執行檔可以先行散布，但必須告知取得程式目的碼與可執行檔的後手，可以同時或嗣後透過何種途徑，進一步取得自由開源軟體元件相關的程式源碼。」這樣的規定，在 GPL、AGPL、LGPL、MPL、CDDL、

EPL 等授權條款裡，都有類似的例示。

以 GPL-2.0 的規定為例（GPL-2.0, § 3）：使用者/開發者可以用目的碼（Objective Code）或可執行形式（Executable Form）散布軟體程式，不過，必須在散布目的碼格式之時，提供一個管道，讓收受者能同時或嗣後取得與目的碼相對應的完整程式源碼。所謂同時，例如以一般人慣用的儲存媒介（如光碟片），

一併將程式執行檔與源碼燒錄其上一併提供，所謂嗣後，例如提供一份電子或紙本文件，告知收受者日後可以合理方式提示此份文件，便可自散布者端接續取得程式源碼。又或者依 GPL-3.0 的規定，可以在網際網路上同一頁面，同時提供程式目的碼與源碼的下載連結，讓下載者自行決定其所欲取得的散布格式⁷。

以 MPL-2.0 的規定為例：倘若使用者/開發者是用可執行形式來發布，則類同 GPL-2.0，必須告知收受者可透過何種合理且即時的方式，去接續取得程式的源碼（MPL-2.0, § 3.2）。

再以 EPL-1.0 的規定為例：若使用者/開發者選擇以目的碼之形式散布軟體，必須闡明該軟體中原屬於 EPL-1.0 授權的部份，

是可以提供程式源碼的，並進一步告知收受者可透過哪些合理方式，或亦可透過一般人慣用儲存媒介的方式，取得這些程式源碼（EPL-1.0, § 3b）iv））。

(三) 授予專利權給使用者/開發者（Grant of Patent License to You）

近年新編撰的自由開源軟體授權條款，多會在條款內容預設專利授權條款，以導引貢獻者將附隨於程式的軟體專利權利，授予給使用者/開發者。這是希望後續使用者/開發者，能安心無虞的利用這些可能含有專利技術的程式，在過往，純粹軟體運算的領域並不常見專利

7 關於 GPL-2.0 規定以目的碼散布的要件，請詳見葛冬梅「授權條款介紹－GNU General Public License 2.0

（GPL）」，http://www.openfoundry.org/tw/licenses/32-gnu-general-public-license-20gpl （最後瀏覽日：2013/12/2）。

的核可，但近年因為許多技術方法的實踐，必須以軟體操作及相關演算法的對應來完成，以致較高軟體性質的專利數量，近年在各國急遽成長，而若不將軟體專利授權的議題帶入授權條款裡預作處理，則自由開源軟體授權的軟體專案，可能便會陷於著作權方面允許改作，但專利權方面授權不清的灰色地帶。故在 APL-2.0、EPL-1.0、MPL-2.0、

AGPL-3.0、GPL-3.0 與 LGPL-3.0 等授權條款，皆包含有這樣的規定。

1. 條款說明

以 APL-2.0 的規定為例：依據此條款的規定，使用者/開發者將被授予永久、非專屬、全球、無償且不可撤回的專利授權，

而可以製造（Make）、使用、為販賣之要約、販賣、進口或移轉該程式（APL-2.0, § 3）。

以 MPL-2.0 的規定為例：在各貢獻者的專利主張下，使用者/

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