授權條款介紹

Academic Free License Version 3.0 (AFL)

2006-11-29T08:00:00Z

一、概覽

AFL 為 Lawrence Rosen (Rosen) 所撰寫，Rosen 是位律師，同時也是位電腦專家，專長為智慧財產權之保護以及科技公司之商業授權與交易相關事務，此外 Rosen 亦擔任開放源碼組織 (OSI) 之首席律師及顧問多年，並持續提供許多非營利性計畫（例如：Apache Software Foundation、Python Software Foundation 以及 Free Standards Group）其法律諮詢。

近年來自由／開放源碼軟體興起，市場佔有率逐漸增加，而專屬軟體業者亦加以反擊，其中一項即為利用軟體專利控訴自由／開放源碼軟體侵權，這兩份授權條款目的便在於使自由／開放源碼軟體對專利權擁有一具體防衛機制（專利中止條款 termination for patent action），若被授權人對授權人提出任何專利相關之控訴，按照授權條款內容，被授權人所被授與之權利將立即自動消失，本特色於「四、專有特色」將有更詳細說明。

二、運用現況

目前在 fresh meat 開發平台上，AFL 所授權之專案約近 50 個，整體的使用率並不高。

三、權利義務

（一）權利：

於著作權有效期限內，授與被授權人不分地區、免授權金、非專屬、可再授權之下列權利：
1. 部份／全部重製原始著作。
2. 翻譯／引用／修改原始著作，以產生衍生著作。
3. 公佈原始著作／衍生著作。
4. 公開執行／展示原始著作。
於專利權有效期限內，授與被授權人不分地區、免授權金、非專屬、可再授權之下列權力：
1. 重製原始或衍生著作。
2. 使用原始或衍生著作。
3. 販賣原始或衍生著作。
4. 引用原始或衍生著作。
可以選擇其他授權條款來散布原始或衍生著作，即使是不提供原始碼或者是收取授權金的授權內容，都是 AFL 所允許的。

（二）義務：

只要被授權人仍繼續採用 AFL 散布原始或衍生著作，則被授權人必需持續提供原始碼。
非經同意，被授權人不可利用授權人或其他貢獻者之姓名或商標，做為商品之背書或促銷用途。
被授權人於衍生著作中須明確標示出對原始著作有所更改 (Attribution Notice)。
被授權人若違反本條款之規定，將立即喪失所被授與之權利。

四、專有特色

該條款第 10 條 Termination for Patent Action 規定若被授權人於任何法院，對任一開放源碼組織承認且含有本條件之授權條款授權之自由／開放源碼軟體提出專利侵權主張，此授權將自動終止，所授予該被授權人之所有權利亦立即終止。AFL 被視為一種使自由／開放源碼軟體免受專利權人傷害之方法。
Attribution Rights：被授權人於其衍生著作之原始碼中，必須明確且明顯地加上 Attribution Notice，內容包括所有其自原始著作中獲得之著作權、專利權以及商標權聲明，並闡明被授權人對原始著作「有」改作。
與 OSL (Open Software License 3.0) 相似，皆為 Lawrence Rosen 所撰寫，且皆含有 Termination for Patent Action 此項目。兩者唯一不同之處僅為第 1 條第 c) 款：AFL 讓被授權人有完全選擇授權條款的自由，也就是無論所散布的 AFL 程式是否經過修改，被授權人均有選擇其他非 AFL 散布授權條款的自由；OSL 則採納 copyleft 機制，也就是無論所散布的 OSL 程式是否經過修改，被授權人均必須繼續採用 AFL 作為程式散布授權條款。因此可以說，AFL 是類似 BSD 的授權條款，OSL 則是類似 GPL 的授權條款。

Apache License 1.1 (Apache 1.1)

2006-10-16T19:57:51Z

Apache 1.1 原文內容請點這裡瀏覽。

一、概覽

Apache 1.1 為 Apache Software Foundation（簡稱 ASF）在 2000 年所提供的。

二、運用狀況

在 ASF 網站上，Apache 1.1 已被歸類為「歷史」，但仍有部份 PHP 模組是使用 Apache 1.1 作為授權條款，例如 Log4J Logging 軟體、XOOPS 部份應用模組。

三、權利義務

（一）被授權人權利

准許以無論有無修改的原始碼或二進位碼形式，為再散布或使用行為，只要符合義務要求即可。

（二）被授權人義務

原始碼的重製物必須包含授權條款的著作權聲明和授權條款的所有內容。
以二進位碼呈現的重製物必須在程式本體或其他說明資料中重現授權條款的著作權聲明和授權條款的所有內容。
若含有終端用戶使用說明時，必須同時包含「此產品所含軟體為 ASF 所開發」的確認訊息，並可與第三者的確認訊息間隔並列。
在沒有事前書面的允許下，"Apache" 和 "Apache Software Foundation" 的名稱不被用於支持或宣傳從本軟體衍生的產品。

在沒有 ASF 的事前書面允許下，從本軟體衍生的產品不得以 "Apache" 稱呼或在名稱中包含 "Apache" 的字眼。

Apache License 2.0 (Apache 2.0)

2006-10-16T19:58:17Z

Apache 2.0 原文內容請點這裡瀏覽。

一、概覽

Apache 2.0 為 Apache Software Foundation（簡稱 ASF）在 2004 年所認可的，目的在於減少問題且可不用修改即可適用任何軟體專案（包括非 ASF 專案的軟體），並將專利條款納入以利於保護任一貢獻者。且任何 ASF 先前開發的軟體均將改以 Apache 2.0 授權。

另為了與其他開放原始碼的授權條款相容，ASF 持續努力讓這版本與 GPL 相容。

二、運用狀況

在 ASF 網站上，Apache 2.0 是所有其專案軟體所使用的授權條款。

三、權利義務

（一）被授權人權利

在權利的授與上，區分著作權和專利兩部分說明之：

著作權授與
允許原始著作與衍生著作永久的、全球的、非專屬的、免費的、免授權金的於再生產時不可撤回的著作權許可：製作衍生物、公開展示、公開演出、再授權和散布。
專利權授與
允許永久的、全球的、非專屬的、免費的、免授權金的於再生產時不可撤回的專利權許可：製造、委託他人代工、使用、供與販售、販售、進口（輸入）及其他方式的讓渡。另有訴訟上抗辯的許可。

（二）被授權人義務

必須對以下五項要求均滿足：

在原始著作或任何衍生著作中包含本授權條款。
在修改的檔案部份必須加上修改聲明。
在所散布的任何原始形式或衍生著作中，除了衍生著作新增或修改與原始著作無關的任何部份外，必須保留所有著作權、專利、商標和著作原始形式來源（原始碼來源）的歸屬聲明 (attribution notice)。
當原始著作包含一個作為散布的「聲明」文件時，在所散布的任何衍生著作中必須包含可閱讀的歸屬聲明檔案，且除了與衍生著作無關者外，必須在下列這些地方之一為之：
1. 將聲明文件檔案作為衍生著作的一部份；
2. 若衍生著作有一併提供原始形式或文件時，在原始形式或文件中包含聲明；
3. 在衍生著作所產生的顯示畫面中，跟第三者的聲明一起出現時，該聲明文件的內容只是參考目的，而並非對授權條款內容作修改時，可在所散佈的著作內增加屬於自身的歸屬聲明。

四、其他重要特性

含有商標使用的限制條款，只有在需要描述作品的來源及再製時的標示時可以使用外，不得使用商標名稱、商標、服務標章和授權人的產品名稱。
還有免責條款及限制責任的條款。但在作品或衍生物的再散布時，再散布者可自由選擇提供責任擔保跟義務的負擔。
是由自由軟體基金會 (FSF) 所認可的自由軟體授權條款，也被開放原始碼組織 (OSI) 認可為開放源碼授權條款，但不與 GPL 相容。

Artistic License (Artistic)

2006-10-16T19:58:49Z

Artistic 原文內容請點這裡瀏覽。

一、概覽

Artistic 原始版本是由 Larry Wall 所撰寫，被用於 Perl 上，但授權條款中有漏洞可供使用者規避授權條款的義務要求，因而被自由軟體基金會 (Free Software Foundation, FSF) 批評不是一個自由軟體授權條款。

而後來 Artistic 出現 2.0 版本 (https://dev.perl.org/perl6/rfc/346.html)，是在為了回應 Perl 社群的對授權條款內容做出解釋的要求下所做成的，而這版本受許多人同意是一個自由軟體授權條款。2.0 版本是自由軟體基金會的 Bradley Kuhn 所撰寫，且在 Perl 第六版發佈時受到採用認可。但 2.0 版本並非開放源碼組織 (Open Source Initiative, OSI) 認證通過的授權條款。

另外有所謂 Clarified Artistic License，也是一個自由軟體授權條款，被 SNEeSe 和 FakeNES emulators 所使用。

二、運用狀況

Artistic 目前被應用在標準 Perl 運作程式、CPAN 組件和 Parrot 軟體上，但都是採 Artistic 跟 GPL 雙重授權方式作為保護。第 6 版的 Perl 則採用 2.0 版的授權條款。

三、權利義務

（一）被授權人權利

可以不受限制的製作並散布使用此授權條款的套裝軟體 (package)。
可以應用源自公共領域 (public domain) 或著作權人的臭蟲（瑕疵）修復、變動修復及和其他關於套裝軟體內容的變動。而被以此類方式修改的套裝軟體仍被視為是標準版本 (Standard Version)。
可以任何其他方式修改被授權人所持有的此一套裝軟體。
可以以目的碼 (object code) 或可執行文件格式散布此一套裝軟體的程式。
可以在散布此一套裝軟體時收取合理的重製費。可以基於支持此套裝軟體收取任何費用。也可以不收取任何費用。
可商業販售。

（二）被授權人義務

要提供複製所有原始著作權聲明和相關捨棄承諾條款的權利。
修改套裝軟體之後所應負之義務：
被授權人須在每一個被改變的檔案開頭處增寫顯著聲明（如何和何時改變了該檔案內容）。並作至少以下一件行為（義務）
- 將修改後的檔案放於公共領域或其他可以自由提供的方式，例如貼文告知、放於主要的搜尋網站或得到原著作權人的同意將修改後的內容放入標準版本中。
- 僅在被授權人自己的公司或組織內使用該修改物。
- 非標準的可執行文件的名稱不可與標準版本的同一文件名稱相抵觸，並另外提供一單獨說明檔說明非標準跟標準版本檔案的差異部份。
- 與著作權人作其他散布協議。
散布時的義務：
- 必須說明可從何處取得標準版本。
- 在散布修改物時必須伴隨散布可供機器讀取的格式。
- 非標準可執行文件須伴隨相同的標準版本的可執行文件，以非標準版本的名稱命名非標準執行文件，並以文件清楚的說明不同處為何，及說明從何處可取得標準版本。
- 與著作權人作其他散布協議。
不得宣傳此一套裝軟體是被授權人所有的。

四、其他重要特性

Artistic 有多處漏洞可供使用者規避授權條款的要求，如第 5 條部份會因授權條款一開始對套裝軟體的定義，而出現不可以單獨販售使用 Artistic 授權的程式，但可以販售包含前述程式的軟體。
另雖要求使用者要讓軟體修改版本可自由使用，但也在第 8 條出現漏洞，使得使用者可以規避而將修改版本歸入私有或只將程式部份釋出到公共領域（不過此第 8 條在部份版本中被移除）。

Artistic License 2.0 (Artisitc 2.0)

2011-03-01T00:00:00Z

Artistic 2.0 原文內容請點這裡瀏覽。

一、概覽

Artistic 2.0 是 the Artistic Licnese (Artistic) 的升級版本。由於 Artisitc 條款的規定有許多模糊不清的地方，並且不相容於應用普遍的 GPL，因此 Perl 基金會 (The Perl Foundation, TPF) 決定改版，並且於 2006 年正式發布 Artistic 2.0。

Artistic 2.0 由 Roberta Cairney 與 Allison Randal 共同執筆撰寫完成，內容除了遵循自由軟體的精神之外，並且承襲前一個版本，將「藝術控制 (artistic control)」作為實踐的理想目的。由於具有這樣的混合目的，因此 Artistic 2.0 並不像 GPL、LGPL 等授權條款會嚴格拘束被授權人利用軟體的方式，但是卻也不會如同 BSD、MIT 等條款的規定幾乎無拘無束，而是有著獨樹一格的權利義務規定。關於「藝術控制 (artistic control)」與相關的 Artistic 2.0 重要規定，可以參考「獨樹一格的藝術條款：Artistic License 2.0」。

二、目前運用狀況

與前一個版本一樣，Artistic 2.0 主要是應用在 Perl 程式語言、CPAN 與 Parrot 等軟體上，其中 Perl 自第 6 版開始採用 Artistic 2.0，而之前的版本則是採用舊版 Artistic 跟 GPL 的雙重授權方式。

三、權利義務

根據 Artistic 2.0，被授權人被授予特定的著作權與大範圍的專利權，而在享有這些權利的同時，被授權人也必須遵守相關的義務規定。

在了解 Artistic 2.0 所規定的權利義務之前，必須要先了解這份條款中所定義的「標準版本 (Standard Version)」與「修改版本 (Modified Version)」這兩個相對的概念。「標準版本 (Standard Version)」是指著作權人所認定的標準版本，所以著作權人自己所發布的軟體與後續改版，都是屬於標準版本，此外，只要是依照著作權人明確指示而修改出來的版本，即使不是著作權人自己所發布，一樣是屬於標準版本。至於其他因為修改了標準版本而產生出來的，就都是「修改版本 (Modified Version)」。透過這樣的分別機制，原 Artistic 2.0 軟體的著作權人可以確保標準版本依照自己堅持的寫作規則與方向來發展，同時他人也藉由「標準版本」這個名詞，可以辨識出哪一個版本是著作權人心中所認可的理想後續版本。

（一）權利

1. 被授權人有權利執行、修改、重製與散布標準版本與修改版本。不過在散布的時候，必須要遵守一些義務規定，這些義務規定請見下面（二）的說明。

2. 散布標準版本的時候，被授權人可以不收取任何費用，但是也可以選擇收取散布費用 (Distributor Fee)，散布費用可以是因為散布行為而產生的費用，或者是提供支援的服務費用。

3. 被授權人在特定範圍之內，可以為修改版本選擇 Artistic 2.0 以外的條款來授權。詳細選擇方式請見下面（二）義務規定說明的第 3 點。

4. 被授權人可以利用軟體中由著作權人合法授權的專利技術，這些利用行為包括製造、代工、使用、販賣、為了販賣而提供給他人、進口以及運輸軟體等行為。而這些合法授權的專利技術是指，著作權人自己擁有的專利技術，或者是著作權人從他人取得、可以再次授權出去的專利技術，由於在這兩種情況下，著作權人擁有全部的專利權或者是取得可以再授權的權利，因此著作權人可以透過 Artistic 2.0 將這些技術的專利權授權出去，讓被授權人在利用軟體的範圍內，可以一併利用這些已經申請、受到專利權保護的技術。

（二）義務

散布標準版本原始碼的時候，被授權人：
1. 必須散布所有完整的原始碼；
2. 必須重製一切的著作權標示與相關聲明，讓後手可以閱讀到這些文字；
3. 可以自行決定是否與編譯過的形式一起散布。
若是要散布修改版本原始碼的話，被授權人必須要詳實記錄修改版本中所有的修改之處，包括與標準版本有哪些不同的功能、可執行檔案或者是任何經過變動的模組資訊等等，以便利原軟體開發團隊能了解修改內容，並在認同修改內容的情況下，將這些修改處順暢地納入後續版本的開發，以達到原軟體專案開發者能持續參與軟體修改與更新除錯的目的。
若是要散布修改版本原始碼的話，被授權人必須在下列三種方式中選擇一項，來為修改版本選定授權條款與散布方式：
1. 選擇 Artistic 2.0 作為修改版本的授權條款，並且主動地讓著作權人可以取得修改版本的程式碼，以方便著作權人將修改內容納入到標準版本中。若是被授權人想要將自己的修改內容回饋給原軟體開發社群，就可以利用這項規定。
2. 選擇其他具有授權拘束性的自由軟體授權條款來授權修改版本，這類條款包括 GPL、LGPL 與 MPL 等，不過並不僅止於這些條款，只要是符合下面三項要件的授權條款，被授權人也都可以採用：(a) 允許他人可以自由重製、修改與再散布修改版本；(b) 他人可以自由取得修改版本與由此再衍生出來程式的原始碼；(c) 散布修改版本與再衍生出來程式的時候，禁止收取授權金，不過可以收取散布費用。關於服務費用請參考上面（一）權利規定說明的第 2 點。若是修改版本必須與 GPL、LGPL 或 MPL 授權的軟體結合成為另一個更大的軟體專案時，就可以利用這項規定，讓原本是 Artistic 2.0 授權的程式碼，順利地與採用這類具有授權拘束性條款的軟體結合在一起。
3. 在符合特定的條件下，被授權人可以選擇任何一份符合自身需求的條款來授權修改版本，例如 BSD、MIT，甚至是不提供原始碼的傳統商業軟體授權條款。而這裡所謂的特定條件有二：一方面修改版本的名稱不可以與標準版本相混淆，必須要讓他人能夠清楚辨識兩者的差異，另外一方面，修改版本的安裝不會影響到標準版本的安裝或執行，也就是說，其他的使用者可以用標準版本來置換修改版本，而整個軟體仍然可以正常運作。若是被授權人預計不採用 Artistic 2.0 或其他具有授權拘束性的條款來授權修改版本的話，就可以利用這項彈性規定，將修改版本與相關的程式碼調整到符合規定的狀態，被授權人就可以為修改版本選擇前兩項以外的條款來授權。
被授權人可以散布標準版本的編譯後形式，不過必須要附上一份完整的說明文件，告知他人如何取得原始碼。而從開始散布標準版本的時候起，這份說明文件的內容就必須是有效的，若說明文件的內容在散布的期間失效的話，被授權人必須要在知悉這樣的狀況起 30 天內，提供新的說明文件或者是取消之前發布的說明文件，否則將會喪失 Artistic 2.0 條款所給予的權利。
被授權人可以散布修改版本的編譯後形式，而散布條件依照修改版本授權條款的規定。而修改版本所採用的授權條款，請被授權人依照上述義務規定說明第 3 點來進行選擇。

四、專有特色

Artistic 2.0 在 2007 年經過開放源碼促進會 (Open Source Initiative, OSI) 審核通過，是一份經過 OSI 核可認證的開放源碼授權條款，此外，自由軟體基金會 (Free Software Foundation, FSF) 也認定這是一份符合四大自由的自由軟體授權條款。
Artistic 2.0 規定有專利報復條款，若是被授權人對任何人提出專利訴訟，並且訴訟內容主張這個 Artistic 2.0 軟體侵害他人專利權的話，那麼從提出訴訟之日開始，Artistic 2.0 授予這位被授權人的權利將全部終止。

BSD License (BSD)

2006-10-16T19:59:16Z

三條款BSD 原文內容請點這裡瀏覽。

一、概覽

The BSD License (BSD) 是 Berkeley Software Distribution License（柏克萊軟體散布授權條款）的縮寫，許多軟體是在此一授權條款下發佈的。因為 BSD 起源自加州大學柏克萊分校，所以最原始散布的 BSD 擁有者是加州大學董事會。又因一些軟體設計師修訂 BSD 的部份內容以做為其軟體程式授權使用，造成 BSD 有多種不同條款內容，統稱 BSD-style 授權條款。

最初的 BSD 是由四個主要條款構成的，其中廣告條款的存在讓許多後來參與修改原始碼的使用者均會將其名字加入聲明之中，而遭受 GNU 計畫 (GNU Project) 的批評：該廣告條款造成非常冗長的聲明內容，是相當不便利，且易發生使用上困擾而與 GPL 不相容。而為了回應 Richard Stallman（GNU 計畫的主導者與 GPL 的起草者），BSD 的官方主導人 William Hoskins 遂在一九九九年七月二十二日率先將該廣告條款自 BSD 中刪除，也引發其他使用 BSD 者的跟進，刪除廣告條款之後的 BSD 被稱為「三條款 BSD」 (3-clause BSD)，而原本的被稱為「四條款 BSD」(4-clause BSD)。

而 BSD 與其他授權條款如 GPL 條款內容相比，是幾乎沒有限制的，因此是更接近公共領域 (public domain) 的。

二、運用狀況

目前實際上的使用是以三條款 BSD 為主，而又因為 BSD 可以任由他人修改條款部份內容以符合使用上需求，因此實務上有許多 BSD-style 授權條款存在。

目前實際使用上，只有 NetBSD 仍然使用四條款BSD；而在某些包含在 KDE 裡面的程式庫使用了二條款 BSD，除刪除廣告條款外，亦將著作權所有者名稱作為背書使用許可的禁止規定去除，而這樣的二條款 BSD 在功能上相當於 MIT；FreeBSD 也是使用二條款 BSD，但另增加了後繼貢獻者的觀點並非 FreeBSD 計畫的官方觀點的額外聲明。

三、權利義務

（一）被授權人權利

允許任何商業上或私有使用。

（二）被授權人義務

在原始碼的重製物中一定要保有本授權條款的著作權標示內容。
以二進位制格式呈現的重製物必須再現本授權條款的著作權聲明和內容。
在沒有事前書面同意的情況下，「the name of the 」及「the names of its contributors」均不得被用於支持或宣傳從既有軟體衍生出的產品（不為產品背書）。ORGANIZATION 視使用 BSD 的使用者名稱而定。

四、其他重要特性

可與其他授權條款並存。
是一個近乎公共領域的授權條款，一般個人或組織可以為了使授權條款內容符合自身需求而更改 ”University of California” 此一標示。
使用 BSD 的軟體程式碼可以被任意使用，代表的是在開放源碼和封閉源碼軟體上均可利用採用此類授權條款的程式碼。
簡單的免責條款。
三條款 BSD 是由自由軟體基金會 (FSF) 所認可的自由軟體授權條款，也被開放源碼組織 (OSI) 認可為開放源碼授權條款。並與 GPL 相容。

Common Public License Version 1.0 (CPL)

2006-11-29T08:00:00Z

CPL 原文內容請點這裡瀏覽。

一、概覽

CPL 由 IBM 所發表，是受開放源碼組織 (OSI) 所認定的開放源碼授權條款，亦是受自由軟體基金會 (FSF) 認定的自由軟體授權條款。用以鼓勵並支持協力開發開放原始碼。

二、運用狀況

最著名的為 IBM 主推的 Eclipse 平台計畫，該開發平台大部分的軟體均使用 CPL 來授權他人使用。除了昇陽 (Sun) 未加入外，Eclipse 整合的絕大部分的 Java 供應商，整合多種工具來撰寫外掛 (plug-in) 程式或測試應用。撰寫外掛程式或將 Eclipse 用作軟體開發應用的開發人員，需發佈其在 CPL 下使用或修改的任何 Eclipse 程式碼，但其可以自由決定自己添加的程式碼的授權條款授予方式。

二、權利義務

（一）權利

非獨家的、全球性的、免授權金的著作權授權授與：被授權人有複製、修改程式、公開展示、公開發表、散布和再授權此一程式的權利（以原始程式、修改程式、原始碼和目的碼形式均可）。
非獨家的、全球性的、免授權金的專利權授權授與：被授權人有製造、使用、販賣、提供販賣、進口（輸入）和其他方式的讓渡（以原始程式、修改程式、原始碼和目的碼形式均可），但只限於軟體型式的專利使用；並不允許硬體型式的專利使用。
每一個參與者（即貢獻者）均可獲得其所貢獻部份（修改增刪程式部分）的著作權，並允許在此一授權條款下提出新版著作權授權條款。

（二）義務

在以目的碼方式散布程式時，貢獻者於其提出的新版授權條款中需符合：
1. 遵從本授權條款；
2. 授權條款需含有明示或暗示的有效地排除所有其他參與者的所有擔保和條件，包括擔保、指明或未指明的條件，和為販賣品或特別目的而生的擔保和條件；
3. 有效地排除所有參與者所有對於直接或間接的、特別的、附帶的和作為結果發生的危險。
以原始碼方式所釋出的程式，在可被利用的時候：
1. 必須依照本授權條款被製成可利用的；
2. 必須每一個程式重製物中將本授權條款納入。

四、其他重要特性

CPL 是 IBM 的律師們為了撰寫一個適合於自由／開放源碼軟體用的授權條款下的產物，試圖作為任何自由／開放源碼軟體均可使用的授權條款範本。
以 CPL 授權的程式碼可與其他授權條款下的軟體進行整合，包含私人（商業上使用）的授權條款。旨在促進程式的商業化使用。
若修改某個 CPL 授權條款的程式，並且散布該修改程式，此時有義務向他人提供修改程式的原始碼。但若只是自己內部使用修改程式，並未對外公開發布這些更改內容，則不必向他人提供修改內容。若編寫並散布的補綴 (patch) 只是與原 CPL 程式碼實現介面操作使用，而未對 CPL 程式碼本身作修改時，也不必將原始碼供大眾使用。故可以適用於計劃未來商業化的自由／開放源碼軟體計畫。
CPL 屬 copyleft 的授權條款，與 GPL 在內容項目上非常相似。主要不同點在專利條款的設計上，CPL 專利授權條款的設計是為了預防他人指控軟體原始碼侵害其（他人）專利，並要求授權費用，因此 CPL 要求貢獻者同意對所有接受者免除授權費用。

Common Develpoment and Distribution License 1.0

2009-05-05T14:26:17Z

CDDL 的內容請點這裡瀏覽。

一、概覽

CDDL 是由昇陽公司草擬，於 2005 年初被開放源組織通過認可，具有完整內容、用詞淺顯、可重複被不同專案使用等特性，但由於是商業公司所起草的授權條款，所以其法律邏輯、內容架構、及文字表達相當清楚且具一致性不相矛盾，屬成熟的授權條款，容易被瞭解及接受。而昇陽公司也表示 CDDL 是以 MPL 1.1 授權條款的內容架構為基礎所制訂出來的條款，所以 CDDL 與 MPL 1.1 的條款內容上有很多相同的特質。

不過，昇陽公司為了使權利人不論是以原始碼或可執行檔形式散布其軟體，均可依 CDDL 授權釋出，而在 CDDL 的條款中以「軟體」這名詞取代「程式碼」。此外，也為了使 CDDL 軟體程式可以被廣泛作商業化或非商業化使用，而在特殊名詞定義部份中，將商業使用字眼刪除。

所以，昇陽公司為了希望 CDDL 授權可以重複被使用，盡量將此授權條款大眾化，並減少對修改程式的貢獻者的限制，以達到吸引軟體權利人使用它的意願。

二、運用狀況

目前會使用 CDDL 的開發專案是以昇陽的產品為主軸而擴散其使用率，主要包括 OpenSolaris、NetBeans、Glassfish 等，但使用 CDDL 的普及度並不高。不過由於有昇陽公司在背後有力的支持相關的社群，所以 CDDL 在自由開放／源碼領域仍有不可忽視的地位。

三、權利義務

(一) 被授權人權利

CDDL 中被授權人的權利是由有權利的著作人授與的，而該著作權的授權人包含有二，一為原始程式開發者，二為程式貢獻者。在 CDDL 中是將除了商標權以外的智慧財產權均授與給被授權人，而其主要詳細授權內容如下：

除了專利權與商標權以外的智慧財產權：被授權人可以使用、重製、修改、展示、執行、再授權以及散布程式的原始碼或修改部份的一部份或全部。
專利權：被授權人可以製造、代工、使用、營業、銷售、為銷售而提出要約以及處置原始程式的原始碼或修改原始程式部份程式中的一部份或全部。而且被授權人針對程式授權人所散布出來的原始碼 (Source code) 可做不同的運用，以不同的方式呈現其相同的專利技術。但有兩種情形沒有專利權的授與，第一種為已被被授權人所刪除的原始程式中的原始碼；第二種為當專利侵害的發生是由於將原始程式修改，或者將原始程式與其他軟體或裝置結合。
被授權人可選用合適的授權條款：
1. 被授權人可將原始程式修改後所產生的可執行檔的版本選擇非 CDDL 條款來授權，不過所選擇的非 CDDL 條款不可限制或改變原來 CDDL 所賦予拿到程式原始碼收受者所應有的權利。
2. 由於 CDDL 條款版本的變動是由昇陽公司制定及釋出的，每一個 CDDL 版本都會有版本號碼。當有新版本的 CDDL 條款釋出時，除非原軟體程式的開發者有聲明不採新版 CDDL，否則被授權人可將其修改散布的軟體程式採用新版本的 CDDL 條款。
被授權人還可以將 CDDL 程式碼與其他程式碼結合在一起，成為一個「更大型的著作 (Larger Work)」，即使這個更大型的著作中的其他程式碼並非適用 CDDL 授權也可以，只要被授權人依照 CDDL 規定遵行義務即可。

(二) 被授權人義務

被授權人散布程式的時候必須遵守下列規定：

所修改的程式版本必須繼續受到 CDDL 條款的拘束，但必須陳明此修改版本是被授權人所創作的，且有權使該程式依 CDDL 散布。
必須提供所散布程式的原始碼並附隨提供一份 CDDL 條款的影本。
當散布的程式是可執行檔的形式時，則必須使程式的收受者知道如何可取得原始碼。
在修改版本中必須有貢獻者的著作權聲明，而且不能去除或變更原始程式內所含的著作權、專利權或商標權的聲明或任何陳述。
不得加入另外會限制該程式適用的 CDDL 版本的條款或限制程式收受者的權利。雖然被授權人得因選擇提供該軟體的保證、支援或擔保而向程式收受者收取費用而負起該負之責任，但程式原始開發者或任何程式貢獻者不須要因此而負任何擔保責任。

四、其他重要內容

程式的原始開發者也就是授權人可以修改 CDDL 條款的文字內容。但必須將該條款重新命名以及清楚標明與 CDDL 不同的條款。
清楚定義何為 CDDL 程式修改版本，使被授權人更清楚其授權的範圍是包含哪些程式。
CDDL 軟體程式的修改版本必須採用 CDDL 作為授權條款。這規定與 GPL 一樣，但 CDDL 比 GPL 有彈性，因 CDDL 授權的感染性是以檔案為基礎，也就是一個程式軟體內可區隔成很多不同檔案，只有採 CDDL 授權的檔案才受 CDDL 授權的拘束而程式軟體內的其他檔案可採別的自由軟體授權條款，而不須受 CDDL 影響。因其想給予商業人士更多彈性將所修改的 CDDL 軟體程式授權給大眾。
CDDL 條款中將附隨程式碼或其內含的文件也定義為「原始碼」的範圍。
當被授權人向授權人提出專利侵權訴訟，控告該授權人所撰寫的程式侵害某專利時，則被告的授權人可以書面撤銷該被授權人的授權。
CDDL 條款中規定程式的授權人須將其專利權授與給被授權人，讓使用者可以安心使用該程式，而不會擔心被告專利侵權的威脅。
CDDL 授權的生效日，可以是以軟體被散布之日起生效，或者是以第三人可利用該軟體之日起算生效。
減化對不必要聲明的要求，因為某些自由軟體授權條款要求著作人針對其程式須附上很多必要的聲明。例如：MPL 授權要求於原始檔案中置入 Exhibit A 使收受者可清楚瞭解原始檔案的開發者是誰、授權條款為何、程式貢獻者有誰等、、、等，但在 CDDL 條款中未規定。
未規定特定管轄法院與準據法，而是交由軟體權利人來自行決定，只要在條款之後加上一份聲明，說明該軟體的管轄法院與準據法即可，但權利人也可不適用特定的管轄法院與準據法。

Common Public License 1.0 (CPL) 與 Eclipse Public License 1.0 (EPL)

2009-05-05T14:43:21Z

CPL 的內容請點這裡瀏覽，EPL 的內容請點這裡瀏覽。

一、概覽

CPL 是由 IBM 針對於其「Eclipse 整合開發環境 (Eclipse Integrated Development Environment, IDE)」（註 1）之下所開發之軟體而設計的授權條款；Eclipse IDE 於 2001 年 11 月由 IBM 貢獻給自由軟體社群使用，便開始了 CPL 的使用。

EPL 則是因為後來 IBM 將 Eclipse IDE 交由名為「Eclipse 基金會 (Eclipse Foundation)」的非營利軟體供應商聯盟來管理，因此於 2004 年針對 CPL 為小部分修改為成的授權條款。

其修改重點：1. 由 Eclipse 基金會取代 IBM 成為 EPL 的管理者；2. EPL 移除了 CPL 第 7 段中的部分專利訴訟的相關條款；除此之外，兩份授權條款全文完全相同，亦即，CPL 與 EPL 所規範的權利義務關係幾乎是完全相同的。詳細內容請見本文「四、專有特色」之內容。

CPL/EPL 此二授權條款皆已受開放源碼組織 (OSI) 及自由軟體基金會 (FSF) 之認可。

時下許多授權條款（例如 GPL）強調「著佐權 (copyleft)」條款（註2），CPL/EPL 也不例外，其係以 copyleft 作為其原則特色，且因 CPL/EPL 在設計時就是希望成為一個更有利於商業使用的自由軟體授權條款，故與 GPL 稍有不同。經由 CPL/EPL 授權的程式可以被使用、修改、複製及散布，亦可修改其程式的版本，釋出者（Contributor）在一定條件下有義務釋出他們自己的更改之源碼。

二、運用狀況

起初，CPL 是由 IBM 專為其 Eclipse IDE 下之程式所設計之授權條款，而後由 Eclipse 基金會則取代了 IBM 作為 Eclipse IDE 的管理者，同時計劃將 CPL 變更為 EPL，並於 2004 年底前將所有開發計畫之授權條款轉為 EPL。故自轉換計畫之後，於 Eclipse IDE 之下所開發之程式皆運用 EPL 進行授權。

惟因 CPL 亦已為 OSI 及 FSF 所認可，且並未被撤銷，故 Eclipse 基金會所擬定之轉換計劃並無法拘束所有原使用 CPL 的釋出者，只能夠鼓勵勸說其轉換為 EPL；故現在並非只能選擇 EPL，亦仍得自由選用 CPL 作為其授權方式。

三、權利義務

（一）權利

收受者（"Recipient"，指任何受領以 CPL/EPL 授權之程式者，含所有釋出者在內）享有一個非專屬性的、全球性的、免授權金的著作權授權授與：收受者有複製、修改程式、公開展示、公開發表、散布和再授權此一程式的權利（以原始程式、修改程式；原始碼和目的碼形式均可）。
收受者享有一個非專屬性的、全球性的、免授權金的專利權授權授與：收受者有製造、使用、出售、要約出售、進口（輸入）和其他方式的移轉此一程式的權利（以原始程式、修改程式、原始碼和目的碼形式均可）；但其適用只限於軟體形式的專利，並且當然禁止對於硬體形式的專利的適用。
每一個釋出者（"Contributor"，泛指最初以 CPL/EPL 釋出其新創程式者，以及收受 CPL/EPL 程式後，修改、新增該程式，並且再行釋出者），對其貢獻釋出之部分（新創、修改、新增程式部分），享有完整的著作權，並允許在此一授權條款下提出他種著作權授權之條款及方式。

（二）義務

釋出者得以目的碼型式散布程式，於其提出個人版本授權條款之情況下，有下列義務：
1. 其個人版本授權條款內容必須合乎本協議中之名詞定義及條件；
2. 其授權協議：
  1. 必須有效排除所有釋出者的所有擔保和條件，明示或默示的，包括擔保、指明或未指明的條件，以及對於暗示性的擔保或條件針對特定目的之可購買性及適用性；
  2. 必須有效地排除所有釋出者所有對於直接或間接的、特別的、附帶的，以及作為結果發生的危險；
  3. 必須說明該個人版本授權條款中與本協議不同之處，亦需說明該不同部分係由該釋出者所提出者，而與任何第三人無涉；以及
  4. 必須說明收受者得向釋出者索取此程式的源碼，並且必須通知被授權人 (licensee) 應如何以合理的方式或通常的軟體互易習慣來取得源碼。
若該程式是以源碼型式釋出者：
1. 該程式必須依此協議使之可得；以及
2. 每份程式中皆必須包含本協議之文件。
釋出者不得移除或變更任何包含於該程式中之著作權聲明。
若釋出者對該程式加以新增或變更，於其散布時，必須使收受者能以正常合理之一般方式得知此新增或變更部分之初始作者（即此處之釋出者）之身份。
若釋出者為商用釋出者 ("Commercial Contributor")，基於本授權條款旨在促進程式的商業利用，釋出者若將 EPL 授權之程式納入商品中出售，其必須保證不會對其他釋出者產生潛在的責任，故須負擔下列義務：
1. 該「商用釋出者」有義務捍衛任何其他「豁免釋出者 ("Indemnified Contributor")」的權益，並使其免於任何起因於商用釋出者之作為或過失，使第三人向與該商用程式相關的豁免釋出者提出請求、起訴及其他法律行為所致之損失、損害及成本負擔等種種不利益。亦即，若法院判決任何其他釋出者亦須負損害賠償責任，商用釋出者則必須為其支付此賠償金額。
2. 此處（CPL/EPL 第四段「商業性散布」）之義務並不適用於任何相關於任何事實上或聲稱上的智慧財產權侵害之請求或損失。
3. 同時，豁免釋出者必須為下列行為，始得要求商用釋出者負擔前開義務：
  1. 一經第三人對之請求、起訴或為其他法律行為，立即以書面通知商用釋出者；
  2. 允許商用釋出者控制，並且在訴訟防禦及任何相關之和解協調亦須與商用釋出者合作。豁免釋出者得自行負擔費用以參與任何此類的請求。

四、專有特色

若程式開發者對於 CPL/EPL 授權源碼，新增程式碼（例如以模組的方式）以改善該程式，只要此部分獨立於原程式以外、非屬原程式的衍生作品 (derivative work)（註 3），而是新的創作作品，則該程式開發者就此更改及新增之部分得自由地採用其他任何不同的授權條款，亦得不公開源碼。反之，若其對於 CPL/EPL 授權源碼修改及新增之部分屬於原作品的衍生作品，則仍須依 CPL/EPL 規定的權利義務關係行之。

若未來 CPL/EPL 發布新版本時，使用者及釋出者得自由選擇以其接收時的版本或以新版本進行散布。

CPL 與 EPL 之差別僅在：

因主體不同，故將 "IBM" 改為 "Eclipse Foundation"；
於第 7 段「通則」(Article 7 “General”) 中，EPL 刪除了 CPL 原有的一段文字，該部分被稱為「專利報復條款 ("patent retaliation" clause)」，意思是指，收受者如果對於釋出者所釋出的程式有疑慮，認為該程式已經侵害了專利權，而提起專利訴訟的話，那麼這個專利報復條款就會對此收受者施予一個報復：即日起終止該程式之授權。故將使收受者不再是合法經過授權，而變成非法侵權的情況了。

以下文字即是原來 CPL 中所有，而在 EPL 中所無（刪去）者："If Recipient institutes patent litigation against a Contributor with respect to a patent applicable to software (including a cross-claim or counterclaim in a lawsuit), then any patent licenses granted by that Contributor to such Recipient under this Agreement shall terminate as of the date such litigation is filed." 本文譯為：若收受者對於專利可否適用於該軟體之爭議，對該釋出者提起專利訴訟（包含交互訴訟或反訴），則在此協議之下，由該釋出者授予收受者之任何專利授權，將於訴訟提出日起終止授權。

在同段中並無刪除所有的專利報復條款，EPL 尚保留 CPL 的一段相關文字："if Recipient institutes patent litigation against any entity (including a cross-claim or counterclaim in a lawsuit) alleging that the Program itself (excluding combinations of the Program with other software or hardware) infringes such Recipient's patent(s), then such Recipient's rights granted under Section 2(b) shall terminate as of the date such litigation is filed." 本文譯為：若收受者對於（包含自然人及法人在內的）任何實體提出專利訴訟（包含交互訴訟或反訴），聲稱該程式（包含該程式與其他軟體或硬體結合在內）已侵害其專利，則本授權條款於第二章 b 段（註 4）所授與該收受者之權利將於訴訟提出時起終止。這部分的專利報復條款仍保留於 EPL 中。

（以上中文說明僅為參考資料，自由軟體授權條款皆僅以英文為法律上之唯一解釋依據。）

五、相關參考文獻

CPL to EPL Transition Plan: https://www.eclipse.org/legal/cpl2epl/CPL2EPLTransitionPlan.pdf (last visited on Mar. 27, 2009)
CPL To EPL Transition Plan Frequently Asked Questions: https://www.eclipse.org/legal/cpl2epl/cpl2eplfaq.php (last visited on Mar. 27, 2009)
CPL from WIKIPEDIA: https://en.wikipedia.org/wiki/Common_Public_License (last visited on Mar. 27, 2009)
EPL from WIKIPEDIA: https://en.wikipedia.org/wiki/Eclipse_Public_License (last visited on Mar. 27, 2009)
Patent retaliation from WIKIPEDIA: https://en.wikipedia.org/wiki/Software_patents_and_free_software#Patent_retaliation (last visited on Mar. 27, 2009)

註 1: Eclipse 是一個多語言的軟體開發平台軟體，（原以 CPL）現以 EPL 授權的自由軟體。它以 Java 為主要語言，但也可以藉由 plug-in 來使用別種程式語言，例如 C/C++, Cobol, Python, Perl, PHP 等等。

註 2: 著佐權 (copyleft) 的精神即在於四大自由（執行程式的自由、研究程式運作的自由、再散布程式的自由、改善程式的自由）及開放源碼 (open source)。四大自由，請參見自由軟體基金會之定義： https://www.gnu.org/philosophy/free-sw.html

註 3: 衍生作品 (derivative work) 一詞出現在 CPL/EPL 的第一段第 b 項第 ii 款 (Article 1 (b) (ii))：Contributions do not include additions to the Program which: (i) are separate modules of software distributed in conjunction with the Program under their own license agreement, and (ii) are not derivative works of the Program. 亦即，獨立的模組以及非屬衍生作品的部分，既不在本授權條款的"Contribution"範圍內，故不須依本授權條款規定的權利義務關係行之。然而何謂衍生作品 (derivative work)，Eclipse Foundation 無明確定義，僅表示由於其司法管轄是適用美國法，故依美國著作權法的定義為準。美國著作權法 (U.S. Copyright Act) 定義衍生作品為： "...a work based upon one or more preexisting works, such as a translation, musical arrangement, dramatization, fictionalization, motion picture version, sound recording, art reproduction, abridgment, condensation, or any other form in which a work may be recast, transformed, or adapted. A work consisting of editorial revisions, annotations, elaborations, or other modifications which, as a whole, represent an original work of authorship, is a "derivative work"."

註 4: 第二章 b 段之權利，請參照本文「三、權利義務（一）權利 2. 收受者享有一個非專屬性的…」之部分。

GNU Lesser General Public License 2.1 (LGPL)

2006-11-29T08:00:00Z

LGPL 原文內容請點這裡瀏覽。

一、概覽

LGPL 是 GNU 計畫針對函式庫 (library) 所編寫的自由／開放源碼授權條款，從字拆解來看為 Lesser GPL，那麼顧名思義，它是較為寬鬆的 GPL 類授權條款，與 GPL 相同的是 copyleft 的精神與開放予公眾分享的意念，不同的則是它引介了部分的彈性規範，與 GPL 最大的不同處，在於 LGPL 定義了連結 (Link) 使用與結合的不同，那麼可以此來分別是否套用 GPL 有的 copyleft 理念，若他程式與依 LGPL 授權的自由／開放源碼軟體程式相結合，則結合後的程式皆須受到 LGPL 的約制，也就是後續散布須使用 LGPL 來做為釋出的授權條款；但若是被定義他程式僅是連結至受 LGPL 約制的函式庫，那麼此時並不強硬拘束所連結的程式定要選用 LGPL 為它的授權條款。自由軟體基金會 (Free Software Foundation) 做出這般不同於 GPL 的設計，主要著眼在於擴展自由／開放源碼軟體的版圖及市佔率來做考量，殆因函式庫的配置，本就是提供許多外部程式讀取資料，若一旦連結即要受 GPL 約制，恐怕不利於增加這些自由／開放源碼函式庫的被使用率。故一言以蔽之，LGPL 乃是針對自由／開放源碼函式庫的推廣，欲擴大其占有率及使用族群所建構出來的折衷條款。

二、運用現況

夾雜著部份 copyleft 的理念，但同時調和其嚴厲性，使得 LGPL 的選用率居高不下，現階段運用狀況良好，許多函式庫有關程式皆取用其來作為釋出條款。

三、權利義務

（一）被授權人的權利

只要散布時明示 LGPL 的著作權聲明及免責條款，並協同此份授權條款一併釋出，被授權人可以完整的重製散布函式庫的完整原始碼。
被授權人從事後續散布行為時，可收取散布過程所支出的費用，被授權人亦可自行抉擇是否對後手收受者提供額外的保障來換取更高的服務費用。
修改衍生著作可依修改者的意思，將函式庫版本轉為受 GPL 約制，只須將授權聲明完全代換過來（可以指定轉化為 GPL 2.0 版或其後新版）。但此過程不可逆轉，亦不可事後撤銷。
被授權人可將函式庫與其他相關程式做結合或連結，產生含有部分函式庫內容的衍生著作。
被授權人可單純的將 LPGL 函式庫與他不受本條款管轄的他函式庫做工具性結合，但不得涉及結構上的相融。

（二）被授權人的義務

須明確標明對函式庫修改的日期及修改部分。
修改過的衍生著作仍得轄於 LGPL 授權條款之下，且不得向任何人以授權金的方式收取費用。
修改函式庫的過程中，善盡維護函式庫完整性的義務，不任意刪除原函式庫的固有功能。
原始碼的提供義務，重製、散布原始程式或衍生著作皆須釋放出相對應的完整原始碼，以一般軟體傳輸所慣習的方式提供後續收受者取用。
衍生著作須同時開放目的碼與原始碼，伴隨程式一同散布。
衍生著作中須做明確的標示，註明程式作品中含有 LGPL 函式庫，且在 LGPL 規範之下，須將 LGPL 函式庫的著作權聲明併同呈現，且須提供連結指引使用者參照 LGPL 的全文。
建立合宜的連結共享機制，維持原函式庫的完整性，以便在函式庫改版修正後仍然可以和一些應用程式維持良好的互動關係。
衍生著作於散布時應提供明確的報價，其效期不得少於三年，在此期間內恒常的提供他人取得目的碼與原始碼的服務，若單獨散布原始碼，此原始碼散布服務本身僅能收求工本費。
不得將 LPGL 函式庫與其他授權條款相衝突的函式庫做連結應用。
如衍生著作採提供特定位置供使用者下載的散布方式，則在相同位置應併同擺放原始碼檔案，僅使用者有一併下載的可能性。
如依第 7 條規定採用綜合函式庫的方式釋出時，須提供恒常的明示告知使用者其中一部分乃是 LPGL 函式庫，並令其知悉如何能取得原始的 LPGL 函式庫版本。
不得對其後的被授權人附加任何原授權條款所無的限制，亦不須對後續被授權人違反授權條款的行為負任何責任。
任何理由不能成為不履行 LGPL 授權條款義務的理由，若與客觀環境不得兩全，則唯一方式是放棄散布 LGPL 函式庫。

四、專有特色

LGPL 乃是針對函式庫推廣，欲擴大自由／開放源碼函式庫的占有率及使用族群所建構出來的折衷條款，故「原則上」僅適用於函式庫或其他實質相類程式。
重點在於建立函式庫與他程式結合緊密度的判準，「基於函式庫」與「使用函式庫」的利用模式產生分野，藉此創立 LGPL 條款的擴張範圍的原則與例外。
衍生著作仍須是函式庫方可繼續適用 LGPL，否則只能轉化為 GPL。
適用 LGPL 的函式庫可在嗣後被轉化為受 GPL 規範，或是衍生著作可取用 LGPL 的函式庫之一部，再以受 GPL 規範的模式進行散布，須注意此過程並不可逆轉，只能由 LGPL 轉化為 GPL，不可反轉這個過程，亦不可肆後撤銷。
LGPL 轉化為 GPL，不可反轉這個過程，亦不可肆後撤銷。
抑制專利權行使的立場，專利爭議、法院命命或任何協議不得和授權條款義務性要求相衝突，如不能兼顧，唯一的處理方式就是自始不進行 LGPL 函式庫的散布。
著作權人可增訂地域性散布限制條款，禁止函式庫在部分國家流傳。