採用自由開源軟體之法制指引

(1)

採用自由開源軟體之法制指引

委辦單位：行政院科技會報辦公室

執行單位：資訊工業策進會科技法律研究所 中華民國 1 0 3 年 1 0 月

(2)

目錄

壹、目的...1

貳、什麼是自由開源軟體 ...3

一、定義...3

(一) 自由軟體...3

(二) 開源軟體...3

二、重要觀念解析...4

(一) 可以拿自由開源軟體進行商業化運用嗎？ ...4

(二) 散布自由開源軟體可以因此收費嗎？ ...5

(三) 自由開源軟體的總持有成本 ...5

(四) 自由開源軟體就是共享軟體嗎？ ...6

參、自由開源軟體授權條款相關議題 ...7

一、如何辨別軟體為自由開源軟體？...7

二、電腦程式為著作權法保護之標的...7

三、從軟體私有到軟體共享（COPYRIGHT TO COPYLEFT）...8

(一) Copyleft 的授權條款 ...8

(二) 非 Copyleft 的授權條款 ...9

(3)

四、自由開源軟體的授權條款在法律上的意義與效力 ...9

(一) 意義...10

(二) 利害關係人 ...10

(三) 效力...11

五、常見授權條款簡介...11

(一) GNU General Public License（GPL）...12

(二) GNU Affero General Public License（AGPL） ...12

(三) GNU Library or "Lesser" General Public License （LGPL） ...13

(四) The MIT License（MIT） ...14

(五) The BSD License（BSD） ...14

(六) Apache License（APL） ...14

(七) Mozilla Public License（MPL） ...15

(八) Eclipse Public License（EPL）...16

(九) Common Development and Distribution License （CDDL） ...17

六、雙重授權...18

(一) 併與一般商業授權模式散布軟體程式 ...18

(二) 對於使用者/開發者的影響 ...18

(4)

七、自由開源軟體授權條款的互惠性...18

(一) 互惠義務是什麼？ ...18

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

(三) 互惠要求的程度 ...19

(四) 互惠要求與風險 ...21

(五) 互惠義務是否被觸發之要素 ...23

八、授權條款間的相容性...28

(一) 相容性...28

(二) 以互惠程度高低判別授權條款是否相容 ...29

肆、採用自由開源軟體之風險辨識與管控 ...31

一、組織採用開源軟體之政策...32

二、依常見的條款詞彙與用語辨識風險 ...37

(一) 衍生程式（Work derived from the Program） ...37

(二) 將程式以源碼的形式散布（Distribute the Program in source form） ...39

(三) 授予專利權給使用者/開發者（Grant of patent license to You）...41

(四) 聲明不負擔保責任（No warranty and disclaimer）...44

(5)

(五) 以相同條件散布（Under the terms of the license） ...0

三、以採用行為與預期用途，選擇合適的自由開源軟體。 ..46

四、組織採用自由開源軟體時應注意的事項 ...57

五、自由開源軟體資料表（組織管理用） ...59

伍、附錄...64

一、常見用語...64

二、實用連結...66

(6)

圖目錄

圖 1：確認需求即早於開發初期揀選合適的自由開源軟體 ...2

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

圖 3：自由開源軟體風險辨識–以互惠義務為主 ...1

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

圖 5：組織「自由開源軟體採用政策」之指導作用 ...36

圖 6：自由開源軟體決策流程圖（請配合「自由開源軟體決策矩陣表」的情境說明閱讀）...1

表目錄

表 1：授權條款類別的風險程度 ...22

表 2：組織「自由開源軟體採用政策」–自行編撰部份的程式源碼不予公開型態之例示 ...33

表 3：自由開源軟體決策矩陣表（請配合「自由開源軟體決策流程圖」閱讀） ...48

表 4：自由開源軟體專案散布向性比較表 ...54

表 5：組織採用自由開源軟體應注意事項表（例） ...57

表 6：自由開源軟體資料表 ...59

(7)

壹、目的

近年我國資訊服務產業的發展，朝著「先軟體後硬體」的策略方向，試圖在我國產製硬體能力的既有基礎上，深化培育軟體人才、挹注軟體研發資源、提升軟體的商業化及智慧財產權價值，以構築良好的資訊服務產業鏈。

其中，自由開源軟體之應用價值漸被彰顯，其不需授權費用及鼓勵多人共工的專有特色，適合取為國內軟體專案研發的基礎，這是因為，過往國內資訊工程領域裡，自主建構的大型軟體專案不多，故若能善用自由開源軟體專案的既成成果，自可將其快速搭配既有的硬體產值，以有效強化資訊服務能量。然而，自由開源軟體所採用的公眾授權條款，種類繁複且用語艱澀，每每讓有商業利用意願的國人望之卻步，擔心因未能窺其全貌而舉措失當。有鑑於此，本指引嘗試以簡單、易讀的方式，簡明詮釋自由開源軟體的授權機制、運作規則、及採用自由開源軟體應行注意的風險控制措施，並使自由開源軟體相關的法律事項得以被使用者快速掌握。

本指引為參考性文件，不具有法律上之拘束力，係就採用自由開源軟體之普遍性事項予以闡釋，不涉及個案法律意見的提供；此外，

本指引並非建立在採用自由開源軟體的強制性作法。其編撰目的，在使軟體使用者或程式開發者（使用者/開發者），對於自由開源軟體相關的一般法律事項有較為充分的認知，而能進一步協助使用者/開發者於確立目的後，即能初步判斷可以或不可以採用特定類型授權條款的自由開源軟體專案，以協助國內之程式開發者能縮短軟體開發時程、節省查找各授權內容之心力。

(8)

圖 1：確認需求即早於開發初期揀選合適的自由開源軟體

資料來源：本研究繪製

本指引撰寫之參考依據，悉為國內外以協助自由開源軟體應用為目的之專業組織（含民間組織及政府機關）所提出的文件或意見。這些組織，主要包含開放源碼促進會（Open Source Initiative, OSI）、自由軟體基金會（Free Software Foundation, FSF）、我國中央研究院自由軟體鑄造場（Open Source Software Foundry, OSSF）、以及近年來大力推動公部門應用自由開源軟體的澳洲、英國等國的權責機關。

(9)

貳、什麼是自由開源軟體

一、定義

自由開源軟體（Free/Open Source Software, FOSS）為自由軟體（Free Software）與開源軟體（Open Source Software, OSS）的合稱，各自有所定義。

(一) 自由軟體

自由軟體基金會（FSF）解釋自由軟體之「自由」，

為自由分享、學習與修改，而這些自由為軟體使用者/開發者所充分擁有。自由軟體運動的倡導者與實踐者史托曼

（Richard. M. Stallman）加以詮釋：軟體「自由」包含執行程式的自由、研究與修改程式的自由、再次散布程式的自由、回饋社群並促進改良其他程式的自由等四大自由，

這樣的軟體並以免授權金（Royalty free）、可自由利用為主要訴求。

(二) 開源軟體

開放源碼促進會（OSI）以兼顧軟體的商業應用及程式源碼自由流通為目的，定義開源軟體必須具備下述要件：

1. 允許自由散布；

2. 包含程式源碼的自由流通；

3. 授權條款允許改作及衍生程式的產生；

4. 需保持原作者程式源碼的完整性（Integrity）； 5. 授權條款對任何個人或群體均應一視同仁，不得有

差別待遇；

(10)

6. 授權條款不得對特定領域或活動的應用有差別待遇；

7. 授權條款所賦予的權利自動適用到每一位程式的收受者；

8. 授權條款所賦予的權利不得專屬於特定產品；

9. 授權條款不得對隨同散布的其他軟體做出限制（例如規定必須同為開放源碼軟體）；

10. 授權的管道必須保持技術中立性，不限制特定方式或平台才能取得。

二、重要觀念解析

(一) 可以拿自由開源軟體進行商業化運用嗎？

只要在商業化運用的過程中遵守個別授權條款的規定，所有的自由開源軟體專案皆可被用來進行商業化運用，當然，這也包括內嵌到商業產品之中進行販售。然而，

在販售相關產品的同時，必須遵守自由開源軟體授權條款的義務性規定，來落實這些義務。例如：標示原專案開發者必要的著作權聲明與免責聲明；而若是條款中規定散布時必須提供自由開源軟體專案的程式源碼時，那麼販售公司就必須在販售產品時，一併提供該開源專案的程式源碼，或是嗣後，讓產品消費者有管道可以索取到相關自由開源軟體專案的程式源碼。

自由開源軟體各授權條款最基本的義務規定，是保留與標示各項權利聲明與免責聲明，重點在於讓自由開源軟體專案的後手使用者/開發者，可以透過電子檔或紙本的形式，閱讀到這些聲明內容。其餘的義務性規定則會因條款特性的不同而有差異，進一步內容可以參考本指引

(11)

「肆、自由開源軟體授權條款相關議題」中「五、常見授權條款簡介」一段的說明。

(二) 散布自由開源軟體可以因此收費嗎？

使用者/開發者可以將自由開源軟體商業化，並可因此而收取費用，不論這個商業化運用行為有沒有涉及自由開源軟體專案的散布，此一收費模式都是可以成立的。但也因為自由開源軟體授權條款的限制，此一收費的名目，

不能夠是限制自由開源軟體專案使用對象、使用時間，與使用地域限制的授權金費用（著作權與專利權方面的授權金），這是自由開源軟體主要的特色之一。

可以收取的費用例如：利用自由開源軟體為客戶開發客製化系統的服務費、後續處理錯誤與定期升級系統的維護費用、訓練客戶公司中資訊管理人員如何管理該套系統的教育訓練費用、處理額外問題的諮詢費用，以及為了將系統程式源碼提供給予客戶，所產生的成本費用等等，均是可以收取的費用。

(三) 自由開源軟體的總持有成本

軟體的總持有成本（Total Cost of Ownership, TCO）

指的是該軟體從被決策採用、實施與操作等各階段所產生的成本；其是以經濟觀點將組織結構與採用軟體等因素綜合考量，不僅可以反映軟體的直接質量，如價格、功能與可信度，也反映出該軟體與組織內廣義技術平台、安裝系統、技能與策略目標、及現有市場與基礎支援服務間的關聯性。

(12)

自由開源軟體與私有軟體（Proprietary Software）兩者的 TCO 比較，是組織（包括公部門與私部門）決策採用何種軟體的重要判斷依循。TCO 之計算與比較應立於公平基礎，應以組織相同的適用範圍、一致的利用期間及廠商提供資訊服務未折扣前的價格予以比較。

(四) 自由開源軟體就是共享軟體嗎？

並非所有免費使用的軟體皆為自由開源軟體。共享軟體（Shareware）雖通常提供使用者免費下載與免費使用，

但有時間或功能限制，且多另有提供付費的商業完整版本，一般來說，這樣的軟體在散布時也不會提供讓使用者得以改作的程式源碼，故亦不允許使用者可以修改軟體。

判斷一個軟體專案是否為自由開源軟體的指標性方法：是該軟體在散布時必須能夠一併提供程式源碼，且允許使用者可以對這些源碼進行使用、修改、重製與再散布。

(13)

參、自由開源軟體授權條款相關議題

一、如何辨別軟體為自由開源軟體？

藉由軟體所標示的資訊，使用者/開發者可以辨識出該軟體是不是自由開源軟體、以及是屬於哪一種授權類型。但是，有時會因為軟體的標示資訊，並沒有放在顯眼之處，而是放在層層網站架構中的某一網頁中¹，而需要多花些時間尋找。若搜尋軟體與其官方網站仍沒有發現相關資訊的話，建議是可以直接與軟體開發專案的作者群聯繫詢問。

二、電腦程式為著作權法保護之標的

電腦程式在我國主要是受到著作權法的保護，其明訂於著作權法第 5 條第 1 項第 10 款：「本法所稱著作，例示包括電腦程式著作。」依據此條，一個電腦程式只要是著作人的智慧結晶，便自動可以取得著作權法下的保護適格，無論這個電腦程式是以自由開源軟體的授權方式，亦或是採私有軟體的授權方式進行後續的應用。

而就現行著作權法的預設著作型態，多人同時同期分工創作且不可分別利用者，其成品可被歸類為共同著作（Joint Work），而若多人前後不同時期接力創作，其後的修改作品可被歸類為衍生著作（Derivative Work）。然而，由於自由開源軟體可能經過成百上千個開發者的參與，故上述二個著作型態與它的實際開發狀態未必完全相符，故實際的授權運作規則，應

1 自由軟體鑄造場，「判斷一個軟體是自由軟體的方法」，http://www.openfoundry.org/news/1880

（最後瀏覽日：2013/12/1）。

(14)

優先比附援引適合的著作權利型態，再佐以自由開源軟體授權條款所律定的補充規則，來適當補充現行法律在著作型態界定上的不足。

三、從軟體私有到軟體共享（Copyright to Copyleft）

將著重於告訴授權人如何「使用」該軟體，也就是說後續運用此私有軟體時，什麼可以做，以及什麼不能做。而自由開源軟體雖然一樣基於此著作權的預設，但其修整過後的中心理念為

「著作權利人保有部份權利（Some Rights Reserved）」，也就是說，只要使用人遵照該自由開源軟體授權條款的規定來運用軟體，則其對軟體是處於一種「深度」的使用地位，不僅僅能夠將此軟體進行安裝使用，還可以在修改之後，以續行分享的態度，將此軟體採一樣的、或變更過後的授權方式再散布出來，

提供給其他人使用。而以類別來論，常見的自由開源軟體授權條款，又可依 Copyleft 特性的有無，分為以下兩大類。

(一) Copyleft 的授權條款

著作權（Copyright）給予著作權人專有利用著作的權利；Copyleft 則表達相反的思維，其主張軟體的自由共享，且希望這樣的精神，不能間斷地延續至所有後續利用到軟體的人。因此在實踐上，當某一個自由開源軟體專案的著作權利人們，認同 Copyleft 的精神時，便可能選用 Copyleft 性質的授權條款來釋出該軟體，律定後續的使用者雖可基於原軟體進行修改與改作，但因此而產生的修改物（ Modification ），或基於原著作而產生的衍生程式

(15)

（Derivative Work），亦應以與原軟體相同的授權條件來進行後續的分享。

部分自由開源軟體授權條款實現了 Copyleft 的精神。舉例而言，軟體若以 GNU General Public License

（GPL）釋出，他人隨後予以修改並散布修改後的修改物與衍生程式，此修改物與衍生程式亦須以 GNU General Public License 釋出，此種內嵌 Copyleft 精神的授權條款，

就是希望相同的分享精神能不斷地適用於後續的修改物與衍生程式中。

(二) 非 Copyleft 的授權條款

幾乎所有主張 Copyleft 的授權條款都是自由開源軟體的授權條款，因為 Copyleft 強調的是一種對程式不間斷的改作自由，此種改作權的給予，恰巧便是自由開源軟體授權模式的核心價值。然而，並非所有的自由開源軟體授權條款，皆主張嵌入 Copyleft 這樣的特性。部份的自由開源軟體專案的推動者，認為完整的改作自由，亦應當包括改作之後，改作人得另行更改授權模式的自由，故也有另一種非 Copyleft 型態的自由開源軟體授權條款，當使用到以這類條款授權的程式專案時，若基於原軟體專案而有所修改，修改之後的修改物與衍生程式，在釋出時並沒有被要求一定得採用相同的授權條款來提供，散布者可視需求採用其他類型的自由開源軟體授權條款來釋出修改物與衍生程式，必要時，也可以將修改物與衍生程式的程式源碼進行封閉處理，進而採用一般商業授權條款的方式來散布。

四、自由開源軟體的授權條款在法律上的意義與效力

(16)

(一) 意義

授權條款是自由開源軟體共工與運用方式的核心，其決定自由開源軟體後續能如何被使用者利用。因此，在自由開源軟體的使用管理上，除了從功能面與技術觀點作劃分外，另外從軟體授權方式的觀點來分類，也有其區別與管理上的正面意義。

(二) 利害關係人

自由開源軟體授權條款除了規定被授權人的權利義務，也會規定與授權人、貢獻者、以及收受者有關之事項。

被授權人、授權人、貢獻者、及收受者是授權條款中常見的利害關係人。

1. 被授權人：經由授權條款之授權而得以利用自由開源軟體的個人或法人。大部分的授權條款採用第二人稱－您（You）稱呼被授權人。

2. 授權人（Licensor）：指著作權人、或取得著作權人之授權而可為授權之實體。

3. 貢獻者（Contributor）：指授權人或代表其他對自由開源軟體有所貢獻（通常指改版、除錯或修補）

者的自然人或法人；且其貢獻成果後續被整併於整體的電腦程式著作裡。在大部分的授權條款中，會明示任一貢獻者將依授權條款授予被授權人自由利用的權利。也有一些授權條款特別聲明保護貢獻者免於受到專利爭訟影響的地位。

4. 收受者（Recipient）：指被授權人以外的程式收受者。有一些授權條款會特別規定，當被授權人散布

(17)

程式時，收受者自動取得原始授權人的授權而可以自由重製、散布及修改程式。

(三) 效力

授權條款為雙方當事人（授權人/著作權人與使用者/

開發者）的法律協議（Agreement），後手使用者/開發者於採用自由開源軟體時，必須選擇符合其利用目的之自由開源軟體授權元件，因為倘若後手使用者/開發者未遵循所選用自由開源軟體元件附隨的授權條款規定，則前手授權人/著作權人，將可能循法律途徑主張其權利或提起訴訟。例如，對於 GPL 及 LGPL 兩類的授權條款違反的舉報事件，在美國的自由軟體基金會（FSF）²、軟體自由法律中心（Software Freedom Law Center, SFLC）、軟體自由託管組織（Software Freedom Conservancy），以及德國的 gpl-violations.org 等權利人團體，都可能依法律途徑主張權利或提起訴訟。

五、常見授權條款簡介

本節透過簡介常見的自由開源軟體授權條款類型，引導使用者/開發者認識授權條款內涵，並能快速掌握重點規範事項。

2 Australian Government, Department of Finance and Deregulation, Australian Government Information Management Office, A GUIDE to OPEN SOURCE SOFTWARE for AUSTRALIAN GOVERNMENT AGENCIES, Version 2.0, June 2011, available at

http://www.finance.gov.au/files/2012/04/AGuidetoOpenSourceSoftware.pdf（last visited Dec. 10, 2013）.

因為某些自由開源軟體的開發者認為自由軟體基金會（Free Software Foundation, FSF）在未遵循授權條款或法律之事件時，具有較為有利之地位提起訴訟，因此常見某些自由開源軟體的開發者會將其著作權利移轉給自由軟體基金會。近來，自由軟體基金會也成功的在美國與歐洲法院提起訴訟，要求強制遵循 GPL 與 LGPL 的授權條款。即使自由開源軟體原始開發者仍保有著作權的情況，FSF 也會提供協調與財務支援以落實授權條款的遵循。

(18)

(一) GNU General Public License（GPL）

GPL 是極為常見的自由開源軟體授權類型，亦是由 FSF 所主力編撰，同時為 OSI 認可的開源軟體授權條款，

目前較常為人使用的為 GPL-2.0 及 GPL-3.0 的版本。依據此類條款，若散布者向外提供了 GPL 授權程式之目的碼

（Binary Form），則從其手上收受程式的後手，便有資格同時或嗣後，向其索取程式之源碼（Source Form）。

此外，使用者/開發者若基於 GPL 授權的程式碼而有所改作（Based on the GPL Program），或是特定元件是依據 GPL 程式碼來進行編寫，並與 GPL 程式緊密連結運作才能發揮特定運算功能，則此一最後成品的衍生作品與結合物，在進行散布時，此衍生與其他依原 GPL 元件所撰寫出來的程式碼，也都應以 GPL 授權條款方式釋出，始得進行散布。

倘若使用者/開發者不打算依 GPL 授權條款的方式，

來釋出該衍生出來的程式碼，則除了純粹內部使用的情形之外，應盡量避免採用以 GPL 為其授權方式的自由開源軟體專案。

(二) GNU Affero General Public License（AGPL）

AGPL 的授權模式與 GPL 幾近相同，唯有於網路使用時的程式源碼提供義務略有差異。AGPL-3.0 版本亦為 FSF 編撰，並經 OSI 認可的自由開源軟體授權條款。此種授權類型，是為因應網際網路時代大量透過網路傳送

（Propagate）或傳遞（Convey）程式的情形。就 AGPL-3.0 的條款內容來說，大部分的規定皆完全同於 GPL 的規

(19)

定，但特別律定：當使用者/開發者基於 AGPL-3.0 授權的軟體程式進行修改或改作後，並讓他人能自遠端透過網際網路與此修改物或衍生程式互動（ Interacting with it Remotely Through a Computer Network），則無論此一修改物或衍生程式的程式碼是否有實質散布，使用者/開發者亦須提供相當管道，讓此修改物與衍生程式的遠端使用者，能進一步取得對應的程式源碼（AGPL-3.0, §13）。

(三) GNU Library or "Lesser" General Public License

（LGPL）

LGPL 是專為自由開源函式庫（Library）軟體所設計的條款，一樣是由 FSF 主力撰寫，同時經 OSI 認可的自由開源軟體授權條款，目前最通用的版本為 LGPL-2.1 版本，以及 LGPL-3.0 版本。

依據此類條款，使用者/開發者基於 LGPL 開源函式庫而產生出來的衍生函式庫，必須在重製或散布該函式庫時，一併釋出此函式庫的源碼格式，或提供相當管道讓後手使用者可以嗣後索取這些函式庫源碼。然而，若使用者 /開發者使用此函式庫的方式，為透過編譯（Compiled）

或連結（Linking）的方式，來讓自己編撰的其他程式元件與此 LGPL 開源函式庫進行運作，只要這個結合的形式並不是被整合為一個單一執行檔（Executive File），則此時連結 LGPL 函式庫進行運作的整體軟體專案，僅會被視為「單純利用函式庫的作品」，而不會構成此函式庫的衍生程式，而這些非屬 LGPL 函式庫部份的程式元件，後續散布時，得毋須依據此類授權條款的規則（LGPL-2.1, § 4, §5）來進行。

(20)

(四) The MIT License（MIT）

MIT 對於基於其授權程式有所改作的情形，並無要求在散布時必須一併提供程式源碼或其他相似供改作的程式碼形式。如不欲繼續提供源碼格式，散布者僅須在程式的複本或實體部份，標示原 MIT 元件作者的著作權聲明與免責聲明，並聲明所提供的衍生版本已不再適用 MIT 來向後授權即可。

(五) The BSD License（BSD）

BSD 對於基於其授權程式有所改作的情形，並無要求在散布時必須一併提供程式源碼或其他相似供改作的程式碼形式。經 OSI 認可的條款為 BSD 3-Clause License 與 BSD 2-Clause License。其規定若以程式源碼的形式散布程式時，必須標示專案作者的著作權聲明及免責聲明；

如果以二進制碼形式（Binary Form）散布，也必須透過適宜的方式，顯現原 BSD 專案作者的著作權聲明及免責聲明。BSD 此點授權特性與 MIT 幾近等價，故如不欲繼續提供源碼格式，散布者僅須在程式的複本或實體部份，

標示原 BSD 元件作者的著作權聲明與免責聲明，並聲明所提供的衍生版本已不再適用 BSD 來向後授權便可。

(六) Apache License（APL）

APL 對於基於其授權程式有所改作的情形，並無要求在散布時必須一併提供程式源碼或其他相似供改作的程式碼形式。如不欲繼續以 APL 授權方式提供源碼格式的檔案，散布者僅須在程式的複本或實體部份，標示原 APL 元件作者的著作權聲明與免責聲明，並聲明所提供

(21)

的衍生版本已不再適用 APL，但新的授權方式亦已包含 APL 條款設定的顯名義務與必要義務來向後授權便可

目前經 OSI 認可，且由 Apache Software Foundation 主力推動的 APL 條款版本為 2.0。APL-2.0 規定可以用程式源碼或目標碼格式（Objective Form）來散布程式或其衍生程式，但必須給予程式收受者 APL-2.0 授權條款全文的複本；如修改了特定檔案，也必須明顯標示此一修改資訊，並在其衍生程式之上，保留 Apache-2.0 授權版本原作者的著作權、專利、商標及歸屬聲明。

(七) Mozilla Public License（MPL）

目前經 OSI 認可，且由 Mozilla Foundation 主力推動的 MPL 條款版本為 2.0。其規定基於 MPL-2.0 授權程式所進行之修改物與衍生程式，後續散布時必須延續以 MPL-2.0 提供程式源碼的方式為之。若是以可執行程式碼

（Executable Form）的形式散布，則必須告知收受者取得程式源碼的合理管道，並且不得向其收取超過散布程序所需的成本費用。

然而 MPL-2.0 有一條特別規定，其律定當使用其他獨立檔案（Separate File or Files）與 MPL-2.0 授權元件併合運作時，該獨立檔案的部份，可以採用與 MPL-2.0 不產生授權衝突的其他授權方式進行釋出（MPL-2.0, § 3.3）。此處所謂不相衝突的授權方式，亦包含不會影響 MPL-2.0 授權義務的其他商業授權條款，也就是說，只要檔案與檔案間具有獨立的區隔性，MPL-2.0 要求衍生程式必須在散布時提供源碼的義務，並不會過繼到其他使用者自行撰寫的檔案裡。

(22)

(八) Eclipse Public License（EPL）

EPL 經 OSI 認可的最新版本為 EPL-1.0，此條款背後的推動與維護組織，為經由 IBM 捐助成立的 Eclipse Foundation。EPL-1.0 條款的內容與結構與 IBM 先行撰擬的 CPL-1.0（Common Public License Version 1）極為相似，

一般多論為其為 CPL-1.0 授權條款的衍生版本，彼此間也具有高度授權義務性方面的近似。EPL-1.0 規定當「程式」

以源碼格式提供時，必須以 EPL-1.0 授權條款的方式來提供；而若以目的碼（Objective Code）格式提供時，則不限定必然要以 EPL-1.0 的授權方式來散布，然而此授權方式亦必須能與 EPL-1.0 相容，且必須告知程式目的碼的收受者，可以透過何種合理管道或媒介來取得 EPL-1.0 授權的程式源碼。

與 MPL-2.0 相似的，EPL-1.0 亦設有特別規定，依其條款對於「貢獻」（Contribution）的解釋（EPL-1.0, §1），

可推知其後手開發者附加於（Addition to）原 EPL-1.0 程式碼的改作或增添，應被認定為被貢獻入 EPL-1.0 專案本體，故後續散布時，也應提供此附加程式的程式源碼或其他可被進行改作的檔案格式³。然而，當此附加程式在功能與結構上，是與原 EPL-1.0 授權的部份具有顯著的區隔性時，則該附加程式可被視為一獨立編寫的功能模組

（Module），該獨立檔案的部份，可以採用與 EPL-1.0 不產生授權衝突的其他授權方式進行釋出。也就是說，只要

3 Karsten Reincke, Greg Sharpe, A practical Guide for Developers, Managers, OS Experts, and Companies- Open Source License Compliance, p.29, available at:

http://dtag-dbu.github.io/oslic/en/oslic/manifesto.html （last visited Dec.1, 2013）.

(23)

獨立撰寫的功能模組與 EPL-1.0 授權部份在功能與結構上具有區隔性，則 EPL-1.0 要求衍生程式必須在散布時提供源碼的義務，並不會過繼到其他使用者自行撰寫的獨立模組上。

(九) Common Development and Distribution License

（CDDL）

CDDL 是由 Sun Microsystems 所編撰，在 Sun Microsystems 為 Oracle Corporation 所收購後，由 Oracle 承繼與維護這份授權條款，此條款目前經 OSI 認可的最新版本為 CDDL-1.0 。 CDDL-1.0 律定，後續散布原以 CDDL-1.0 授權的程式源碼，必須也一樣採 CDDL-1.0 的授權方式（Only Under the Terms of this License），而其他基於 CDDL-1.0 授權程式所進行之修改物與衍生程式，後續散布程式源碼時也必須一樣延續 CDDL-1.0 的授權方式。

然而，若是以可執行程式（Executable Form）格式釋出，則此可執行程式的授權方式，便不必然受限於 CDDL-1.0。此可執行程式的授權方式，可由散布者自行界定，然而所選擇授權方式，必須同時與 CDDL-1.0 基本授權規定相合，且並無進一步限制或轉換 CDDL-1.0 授權條款所賦予程式收受者權利的前提下，才可以被採用。附帶一提的是，CDDL-1.0 在編撰過程裡，是採納 Mozilla Foundation 釋出的 MPL-1.1 為範本，故前述 MPL-2.0 律定獨立檔案不必然會被視為程式源碼衍生範圍的規則，在 CDDL-1.0 授權的軟體專案裡，也原則上適用。

(24)

六、雙重授權

(一) 併與一般商業授權模式散布軟體程式

當軟體散布時同時採用一般商業授權模式及自由開源軟體授權模式，讓使用者得以選擇其取得軟體的授權方式時，為雙重授權（Dual License）模式。此模式之運作，

是為同時兼顧若干群體對於多人共工進行軟體優化的需求、以及若干使用者/開發者可以同時對該軟體專案進行傳統式商業化應用的需求。

(二) 對於使用者/開發者的影響

常見雙重授權，是採用 GPL 授權條款及一般商業授權條款併行的模式。當使用者/開發者不欲受到 GPL 高度互惠要求的限制時，可轉以付費購買商業授權版本，即毋須奉行後續散布程式，必須同時或嗣後提供程式源碼的義務。當使用者/開發者願意遵循互惠要求時，則可以經由 GPL 授權條款，以自由開源軟體的授權模式，取得利用與後續改作該軟體專案的權利。

七、自由開源軟體授權條款的互惠性 (一) 互惠義務是什麼？

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

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

(25)

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

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

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

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

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

（Propagate）予他人。

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

(三) 互惠要求的程度

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

資料來源：本研究繪製

(26)

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

1. 高度互惠要求

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

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

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

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

2. 中度互惠要求

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

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

與 EPL 為代表。

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

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

(27)

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

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

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

3. 低度互惠要求

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

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

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

(四) 互惠要求與風險

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

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

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

(28)

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

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

授權條款

中互惠性 授權條款

低互惠性 授權條款

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

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

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

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

(29)

(五) 互惠義務是否被觸發之要素

如前所述，授權條款的互惠義務，主要是因為使用者對原程式碼有進行「修改」，或是編撰「衍生程式」（並加

「散布」（Distribution）之情形，才會被觸發。不過，究竟什麼樣的情狀會構成「衍生程式」及「散布」，就個別自由開源軟體授權條款內容的解釋，其界線上並不是十分明確，而目前全球的法律實務上，也仍缺乏足夠的判決先例足資引為參考指標。

未遵循互惠性要求

高度互惠性 例如：GPL

中度互惠性 例如：MPL

採用行為與預期用途：衍生與散布

權利人或權利託管機構可能循法律途 徑主張著作權利或提起司法訴訟 具提供衍生程

式源碼之義務

可能具提供衍 生源碼義務

不具提供衍生程式源碼 之要求與義務 授權條款義務

之觸發

互惠程度愈高的授權條款其義務性規 定愈容易被觸發 詳細檢閱授權條款之內容

確認所採用之軟體為 FOSS 確認需求、尋找軟體

授權條款的互惠要求

低度互惠性 例如：BSD, MIT, APL

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

(30)

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

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

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

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

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

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

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

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

(31)

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

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

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

(32)

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

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

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

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

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

(33)

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 的規定，該使用者/開發者傳遞或散布其修改、改作部分的程式碼給他人，使用者/開發者就應履行下列相關義務：

(34)

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

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

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

八、授權條款間的相容性 (一) 相容性

自由開源軟體授權條款的相容性，主要是指程式碼之間能否直接融合運用（Merge），一般常見的融合狀態，有下述兩種情況⁴：

1. 使用者/開發者採用一個以上不同授權狀態的軟體元件（Component），結合開發成為另外一個軟體專案（Project），這些被採用元件的授權條款，在授權義務上並不相互衝突，這些授權條款彼此間，

就具有授權相容性。

2. 使用者/開發者修改程式，被修改的部分採用其他程式的程式碼，這些被採用的程式碼，其原本所適

4 自由軟體鑄造場，「相容性」，http://www.openfoundry.org/tw/compatibility-of-licenses （最後瀏覽日：2013/12/5）。

(35)

用的授權條款，與被修改程式的授權條款間並不相互衝突，這些授權條款彼此間，就具有授權相容性。

(二) 以互惠程度高低判別授權條款是否相容

不同的授權條款彼此間是否相容，必須配合不同軟體的結合情形予以個案詳究；下述以互惠程度進行判別，僅係初步的判斷參考，不能作為判別授權條款是否相容的唯一標準。

1. 具高度互惠要求的授權條款，不容易與其他的授權條款相容，比較常見的狀況是吸收其他互惠要求較低的授權條款，使其後程式整體一併轉為高度互惠要求的授權條款，並依其分享義務而釋出衍生程式的程式源碼。

2. 具中度互惠要求的授權條款，除直接修改其程式本體，須以相同授權條款釋出程式源碼，與其他輔助程式進行後續修改的檔案外，其他自行獨立編寫的檔案，以及架構上具獨立性與區隔性的功能模組，

則可以自行採用其他自訂的授權條款。此類的授權條款，本身已考量到與其他授權條款相容的彈性。

3. 具低度互惠要求的授權條款，對於被授權人後續是否釋出其修改與改作部份，或再散布原軟體、修改物，與衍生程式時應採用何種授權條款，皆無設限，因此實務上除了 APL-2.0 與 GPL-2.0 因為軟體專利授權條款而被 FSF 認為彼此不相容外（然而 APL-2.0 授權條款與 GPL-3.0 授權條款具有相容性），其他此一類型的授權方式，幾乎可以與任何

(36)

一種授權條款相容，也容易被高度互惠要求的授權條款所吸收。

(37)

肆、採用自由開源軟體之風險辨識與管控

接續對於授權條款以及採互惠程度，作為判斷授權條款運用風險之基礎認識後。本指引大要為讀者披露了右列幾個採用自由開源軟體進行商業化運用的基礎概念與要點：

1、自由開源軟體專案仍受著作權利保護；

2、故其運用規則應回歸著作權法的預設，再佐以個別授權條款的細項補充規定；

3、將自由開源軟體運用在商業行為上是符合自由開源軟體授權規範的，但同時商業行為的模式，亦必須符合其各項義務性要求；

4、各自由開源軟體專案基礎的義務性要求，即為程式碼經採用後，無論是否經修改或改作，後續散布上必須保留原作者的著作權聲明以及免責聲明，並夾附一份授權條款電子檔或紙本全文一併散布；

5、除了標示上的義務外，限制型（GPL、AGPL）與限制混合型

（LGPL、MPL、CDDL、EPL）的自由開源軟體授權條款，還會帶有高度與中度的互惠性要求，簡要來說，使用者對此二類授權程式進行修改或改作，其後續產生的修改物與衍生程式，在散布上也有可能必須依照一樣的授權方式，來同時或嗣後提供經修改或改作後的程式源碼，除非能夠依照個別授權條款內容的律定、該專案著作權利人預先的公告，或是一般實務上的通說見解，來主張自我編寫的部份係為獨立運作的程式。

故現行對採用自由開源軟體之風險辨識與管控，核心議題便在於商業化運用的使用者，如不欲提供修改物與衍生程式的程式源碼，以防護其最新的技術方法與商業秘密，則必須就自由開源軟體專案的互惠性要求有所認識，並就商業產品與相關服務的向性為基礎，律定不

(38)

與其商業模式產生衝突的管理政策，並以此政策為規劃依歸，揀選適合使用的自由開源軟體授權專案。

因此，本章將就常見的授權條款予以分析，以此提供組織、使用者/開發者，幾項簡易辨識風險與管控的工具圖表，除提醒組織需建置自由開源軟體之管理政策外，進一步協助組織、使用者/開發者，

配合使用行為與預期用途篩選合適（特定）授權類型的自由開源軟體，以遵循授權條款的方式採用自由開源軟體，及早規劃軟體運用及研發，減緩授權條款所引起的風險⁵。

一、組織採用開源軟體之政策

使用者/開發者採用自由開源軟體，必須遵循其授權條款規定。因此，特別是企業或行政機關等組織，宜依循自身商品的販售模式或管理模式，考量各類型自由開源軟體授權條款要求之可接受度，逐步發展出自己的「自由開源軟體採用政策」，劃出各類預期用途下之界線，以使組織內部人員在採用自由開源軟體時，能有明確依據，降低非預期的法律義務風險。以企業

「不擬即期釋出程式源碼、避免核心技術外流」之狀況為例，

其「自由開源軟體採用政策」或可訂定如下：

5 本章節僅就常見的授權條款予以分析，無法窮盡分析各種自由開源軟體授權條款。若有不明者，使用者/開發者宜再藉由其他專業協助，以確認軟體是否為自由開源軟體，及其應遵循事項。

(39)

表 2：組織「自由開源軟體採用政策」–自行編撰部份的程式源碼不予公開型態之例示

限制型授權條款 限制混合型授權條款 寬鬆型授權條款

授權條款的要求  應標示原專案著作權聲明以及 免責聲明

 對程式本體進行修改、改作，或 依其為基礎編撰運作上無法切割的延伸元件時，整體將被視為一統合作品（As a whole），後續散布時，必須依一樣的授權條款，提供此統合作品的程式源碼。

 應標示原專案著作權聲明以及免 責聲明

 對程式本體進行修改、改作，並後 續散布時，必須依一樣的授權條款，提供修改物與衍生程式的程式源碼；然其他個別撰寫的獨立檔案、模組，或純粹以連結方式與程式本體建立呼叫存取關係的獨立元件，則可選用其他與程式本體授權不相衝突的其他授權方式。

 應標示原專案著作權聲明以及免 責聲明

 不論對程式本體進行修改、改作與 否，後續散布程式時，皆不會啟動互惠性要求。

僅內部使用  無論修改、改作與否，皆可置於 組織內部，作為開發工具或管理平台進行運用；然而，必須確定依此軟體專案進行開發輔助時，並不會自動夾附其程式源碼至開發成果，並隨著成果將程式碼散布至組織外部。

 如採用的為 AGPL-3.0 授權的軟 體專案，必須將其置於單純對內的網路環境（Intranet）上使用，

以避免啟動其網路式的互惠要求。

 無論修改、改作與否，皆可置於組 織內部，作為開發工具或管理平台進行運用；然而，必須確定依此軟體專案進行開發輔助時，並不會自動夾附其程式源碼至開發成果，並隨著成果將程式碼散布至組織外部。

 無論修改、改作與否，皆可置於組 織內部，作為開發工具或管理平台進行運用。

預期再散布  原則不允許使用此類軟體，更不  原則允許使用此類軟體，但不得以  允許使用此類軟體，並得以其為基

(40)

限制型授權條款 限制混合型授權條款 寬鬆型授權條款 得以其為基礎，產生衍生程式。

 如例外可明白確認特別的互動 關係，得讓自行編寫的程式碼，

除外於自由開源軟體授權條款的互惠範圍內，則可在此基礎上進行獨立程式的自行編撰。（例如：應用程式透過一般系統呼叫的方式，來使用 GPL-2.0 授權之 Linux Kernel 的功能；或進一步透過 Android 即時系統與函式庫中介的方式，來與 Linux Kernel 互動。）

 後續散布時，得將自由開源軟體 授權部份與自行編寫的部份結合為一統合專案，併以目的碼的形式進行散布。

 原自由開源軟體授權部份的程 式源碼，必須額外以其原始條款，同時或嗣後向收受程式目的碼之人，應其需求提供程式源碼，此程式源碼的範圍，須含括自由開源軟體程式與其他自行編寫程式之間的互動資訊，包括安裝資訊（Installation

Information）以及編譯腳本

（Compiling Script），方為充足。而無論是以程式源碼形式或目的碼形式，散布此部份的程式

其為基礎，產生衍生程式。

 自行編寫的部份，須確認其與自由 開源軟體授權部份的互動關係，符合授權條款律定的除外範圍（例如：MPL、CDDL–獨立檔案；EPL、

CPL–獨立模組；LGPL–具獨立性的連接關係。），以確保自行撰寫部份程式碼的授權型態，不會受到自由開源軟體授權部份的互惠拘束。

 後續散布時，得將自由開源軟體授 權部份與自行編寫的部份結合為一統合專案，併以目的碼的形式進行散布。

 原自由開源軟體授權部份的程式 源碼，必須額外以其原始條款，同時或嗣後向收受程式目的碼之人，應其需求提供程式源碼。而無論是以程式源碼形式或目的碼形式，散布此部份的程式碼，皆應標示原專案作者之著作權聲明以及免責聲明。

礎，產生衍生程式。

 後續散布時，得將自由開源軟體授 權部份與自行編寫的部份結合為一統合專案，併以目的碼的形式進行散布。

 可視情況自行決定，是否額外以原 自由開源軟體授權程式之原始條款，提供其程式源碼，此點非必要性義務。

 無論是以程式源碼形式或目的碼 形式，散布原屬自由開源軟體授權的程式，皆應標示原專案作者之著作權聲明以及免責聲明。

(41)

限制型授權條款 限制混合型授權條款 寬鬆型授權條款 碼，皆應標示原專案作者之著作

權聲明以及免責聲明。

其他管理措施 當決定採用自由開源軟體專案元件來進行程式開發與運用時，應採行下述措施：

1. 應了解軟體管理上的風險，並遵守授權條款規定，定期進行追蹤與查核。

2. 應協助客戶理解自由開源軟體的授權規則，並適時將所使用的自由開源軟體專案清單提供給客戶。

3. 應使客戶或業主以書面接受使用條件，以具體釐清上下游所應共同遵守與分擔的授權義務。

資料來源：澳洲稅務辦公室之實作，本研究改寫

(42)

倘組織訂有「自由開源軟體採用政策」，組織內部人員即可結合前述風險辨識流程，大致瞭解得否採用特定授權型態的自由開源軟體專案，避免對於組織營運及後續的產品販售，造成智財權管理上的風險（請參照下圖）。

圖 5：組織「自由開源軟體採用政策」之指導作用

資料來源：澳洲稅務辦公室之實作，本研究改寫寬鬆型

確認 FOSS 授權條款之類型 軟體解決方案將採用

FOSS

是否預期產出衍生程式？

是否預期散布衍生程式？

依組織所定之「自由開源軟體採用政策」，未被事先明文禁止，且符合產品向性時始得採用。

限制混合型限制型

是否確認僅於內部使用？

(43)

二、依常見的條款詞彙與用語辨識風險

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

(一) 衍生程式（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 授權的軟體專案或其任

(44)

一部份，會構成「基於此開源程式的作品」（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）

(45)

的衍生關係，此時 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）。

(46)

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

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

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

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

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

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

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

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

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

(47)

以 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）。

(48)

的核可，但近年因為許多技術方法的實踐，必須以軟體操作及相關演算法的對應來完成，以致較高軟體性質的專利數量，近年在各國急遽成長，而若不將軟體專利授權的議題帶入授權條款裡預作處理，則自由開源軟體授權的軟體專案，可能便會陷於著作權方面允許改作，但專利權方面授權不清的灰色地帶。故在 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 的規定為例：在各貢獻者的專利主張下，使用者/

開發者將被授予全球、無償且非專屬的專利授權（MPL-2.0, § 2.1）。

2. 中止授權

在保護使用者/開發者，免於受到任何因使用自由開源軟體所引發的專利爭議外，自由開源軟體授權條款裡預設的專利條款，通常也會同時保障貢獻者免於受專利侵權訴求的追索，這是因為此類專利條款的設置目的，主要在於降低專利權利與自由開源軟體領域自由修改理念的衝突，因而會有如下規定：倘若使用者/開發者宣稱該程式或併入該程式的任一元件，構成專利權的直接侵害或輔助侵害，而對任何法人或自然人提起訴訟（包含交叉訴訟、或訴訟程序中進行反訴），則基於此授權條款所授予這位使用者/開發者的專利權，將自其提起訴訟之日終止（Terminate）。

(49)

3. 補充說明

在 GPL-2.0 以及 LGPL-2.1 的條款中，對於程式的撰寫者與貢獻者，是否授予專利權利予後續的使用者/開發者，並無明確的規定。此兩款條款在序言（Preamble）部份的說明，雖表達出自由開源軟體飽受軟體專利威脅的事實，並希望此種現象能藉由專利權人不去主張專利權利而能得到紓解，但卻沒有進一步規定使用者/開發者可以獲得專利授權，不過，也有論者認為依 GPL-2.0 第 7 條的反面解釋（For example, if a patent license would not permit royalty-free redistribution of the Program by all those who receive copies directly or indirectly through you, then the only way you could satisfy both it and this License would be to refrain entirely from distribution of the Program.），若專利權的主張與軟體得以自由修改與散布的態樣不能被同時實現，那麼 GPL-2.0 授權條款的建議是，此一軟體元件自始便不該被進行散布，也就是說，貢獻者一旦採 GPL-2.0 授權條款的方式將軟體向外提供，並同時將自己事前事後擁有的專利技術撰寫到程式的運作結構裡，那嗣後是不能以其專利權利人的身份，去妨與 LGPL-3.0，條款內容已事先內置了專利授權條款，其撰寫者與開發者，會主動將相關的軟體專利技術併入程式碼裡面，

同時併以 GPL-3.0、LGPL-3.0 的授權規則向後授權，也就是說，如果程式後手的使用者，是依循 GPL-3.0 與 LGPL-3.0 的授權方式來使用相關的軟體程式及軟體專利，將此專利技術寫入程式碼的專利權人，便不能夠向這些使用者提起專利侵權的訴訟。