本節透過簡介常見的自由開源軟體授權條款類型，引導使 用者/開發者認識授權條款內涵，並能快速掌握重點規範事項。
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 也會提供協調與財務支援以落實授權條款的遵循。
(一) 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 的規
定，但特別律定：當使用者/開發者基於 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）來進行。
(四) 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 元件作者的著作權聲明與免責聲明，並聲明所提供
的衍生版本已不再適用 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 要求衍生程式 必須在散布時提供源碼的義務，並不會過繼到其他使用者 自行撰寫的檔案裡。
(八) 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 專案本 體，故後續散布時，也應提供此附加程式的程式源碼或其 他可被進行改作的檔案格式3。然而，當此附加程式在功 能與結構上，是與原 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）.
獨立撰寫的功能模組與 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 授權的軟體專案裡，也原則上適用。
六、 雙重授權
(一) 併與一般商業授權模式散布軟體程式
當軟體散布時同時採用一般商業授權模式及自由開 源軟體授權模式，讓使用者得以選擇其取得軟體的授權方 式時，為雙重授權（Dual License）模式。此模式之運作，
是為同時兼顧若干群體對於多人共工進行軟體優化的需 求、以及若干使用者/開發者可以同時對該軟體專案進行
是為同時兼顧若干群體對於多人共工進行軟體優化的需 求、以及若干使用者/開發者可以同時對該軟體專案進行