Licenses

Academic Free License Version 3.0 (AFL)

2006-11-29T08:00:00Z

I. Overview

Academic Free License 3.0 (AFL) was written by Lawrence Rosen. Rosen is both an attorney and a computer specialist. He specializes in intellectual property protection, business licensing and transactions for technology companies. In addition, Rosen also served as general counsel and secretary of the Open Source Initiative (OSI) for many years, and advises many non-profit projects, such as the Apache Software Foundation, the Python Software Foundation, and the Free Standards Group.

As the free/open source software emerges and its market share increases, proprietary software companies have made several attempts to respond. One of them is to commence actions alleging patent infringement of free/open source software. The AFL and the Open Software License 3.0 (OSL) are designed to protect free/open source software with a defensive strategy – the "termination for patent action" clause. According to the AFL, the rights granted to the licensee by the licene shall terminate automatically if the licensee commences an action for patent infringement against the licensor. This feature will be further explained in details in the following paragraph of "IV. Unique Features".

Apache License Version 1.1 (Apache 1.1)

2006-10-16T19:57:51Z

I. Overview

The 1.1 version of the Apache License was approved by the Apache Software Foundation (ASF) in 2000.

Apache License Version 2.0 (Apache 2.0)

2006-10-16T19:58:17Z

I. Overview

The 2.0 version of the Apache License was approved by the Apache Software Foundation (ASF) in 2004. The goals of this license revision are to reduce the number of frequently asked questions, to allow the license to be reusable without modification by any project (including non-ASF projects), and to require a patent license in order to protect any contributors. Any software developed by the ASF before shall be switched to the Apache 2.0.

To allow this version of the Apache License compatible with other open source licenses, the ASF is still trying to make it compatible with the GPL.

Artistic License（Artistic）

2006-10-16T19:58:49Z

I. Overview

The original Artistic License was written by Larry Wall and was used by Perl. Since the original version has some loopholes that may allow users to circumvent the obligatory requiments of the license, the Free Software Foundation (FSF) has been criticizing that it is not a free software license.

The Artistic 2.0 (https://dev.perl.org/perl6/rfc/346.html) was later brought up in response to the Perl community’s requests of interpreting the license. This version is generally deemed as a free software license. The Artistic 2.0 was written by Bradley Kuhn, who works for FSF, and was adopted by the standard Perl implementation when version 6 was released. However, the Artistic 2.0 is not a free software license approved by Open Source Initiative (OSI).

There also exists a “Clarified Artistic License” (https://www.statistica.unimib.it/utenti/dellavedova/software/artistic2.html), which is also a free software license, currently being used by the SNEeSe and FakeNES emulators.

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, 3-clause BSD License)

2006-10-16T19:59:16Z

I. Overview

The BSD License (BSD) is the abbreviation of Berkeley Software Distribution. Many softwares were distributed under this license. Because the BSD originated from the University of California, Berkeley, the owner of the first released BSD is the Regents of the University of California. Due to the fact that quite a few programmers have amended the BSD for their own license use and have created the divergent versions of the BSD, these licenses are altogether referred to as the “BSD-style” licenses.

The first release of the BSD comprises four main clauses. Among them, the “advertising clause” has caused many users who have amended the source codes being listed on the acknowledgments, and were critized by the GNU Project for it has made the acknowledgments particularly lengthy and clumsy. Besides, it may be incompatible with the GPL. To respond to Richard Stallman’s criticism (the leader of the GNU Project and drafter of the GPL), official leader of the BSD –William Hoskins – has first deleted the advertising clause on July 22, 1999 and a lot of the BSD users have followed. After deletion, the BSD is called the 3-clause BSD, while the old version was referred to as the 4-clause BSD.

Compared to other licenses such as the GPL, the BSD is almost of no limitations. Therefore, it is also closer to the public domain.

Common Public License Version 1.0 (CPL)

2006-11-29T08:00:00Z

I. Overview

The Common Public License (CPL) is published by IBM. It is a free/open source software license approved by the Open Source Initiative (OSI) and the Free Software Foundation (FSF). The aim of the CPL is to encourage and support collaborative open source development.

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 Public License Version 2.1 (LGPL)

2006-11-29T08:00:00Z

I. Overview

The LGPL2 is a free/open source software license written by the GNU Project, and was specifically designed for libraries. As the name LGPL implies, it is a milder GPL-like license. The identical parts of the GPL2 and the LGPL2 are the copyleft spirit and the idea of public share, while the main difference between the two is that the LGPL2 includes some more flexible clauses. The LGPL2 defined “link” and “combine” as different terms, and determined whether programs should include the GPL/copyleft sort of provisions based on this difference. Whenever combined with a LGPLed free/open source software, the newly combined programs must also be licensed under the LGPL2. Nonetheless, if the program is merely linked to a LGPLed library, they are not obligated to use the LGPL2. The reason for Free Software Foundation (FSF) to make the LGPL2 so differently from the GPL2 is to encourage the widest possible use of free/open source software. Since libraries are designated to provide external programs with opportunities to access certain data, a GPL2 limitation must actually decrease the popularity of these free/open source libraries. In a nutshell, the LGPL2 was a compromise made to promote free/open source libraries as well as to expand its market share and user community.