一般人對於自由開源授權條款的運用，都是原封不動地將條款套用到程式上，不過也有些情況是專案開發者對於程式運用方式有特定想法，此時不見得所有授權條款均可以符合開發者的特定想法，因此就會有修改授權條款的需要。

一份授權條款是否容許他人自行修改後使用，就要看當初草擬條款的著作權人是否授權修改，而是否授權修改可以從看條款本身的規定或者是其著作權聲明中得之。

有些條款在授權文字中即有規定使用者可以修改條款內容，但是修改過條款必須使用與原條款不同的名稱，避免他人與原條款混淆，例如 AFL-3.0、OSL-3.0 與 MPL-1.1（註一）均有類似的規定。

最著名的 GPL-2.0 與 LGPL-2.1 則是在條款一開始之處，透過條款的著作權聲明，明示禁止他人修改條款內容，此外，這兩份條款還規定，任何一位使用者都不可以對程式後續收受者的權利增加任何限制，因此一般人僅可以單純地使用 GPL-2.0/LGPL-2.1 來授權自己的程式，並無法修改條款內容後再來使用（註二）。

不過這並不代表完全沒有轉寰之道，GNU 計畫下也有一些專案是採用增添「除外條款 (exception)」的方式來調整 GPL 授權條款的細部規定，例如：GNU Classpath 與 GNU Compiler Collection (GCC) 便是採用 GPL-2.0/GPL-3.0 + exception 的方式授權（註三），此一專案之所以可以採行這樣的作法，第一點、除外條款是經過該專案所有權利人的一致同意與許可；第二點、除外條款的內容是從專案著作權利人的觀點，進一步補充說明 GPL 條款文字的定義範圍，例如 10 行之內程式碼的取用是否讓新程式該當於原程式的衍生作品，或是編譯過程自動帶入的程式碼會不會讓編譯成果變成原程式的衍生作品；第三點、這些除外條款的內容，對於收受程式後手依據 GPL 授權條款所能取得的權利並沒有加以限制或是減少，某個程度反而是擴大與增加，所以亦不會有造成 GPL 條款禁止的「增添條款本身所無之限制 (You may not impose any further restrictions on the recipients' exercise of the rights granted herein.)」的爭議。

另外一個例子則是 AGPL (GNU/AFFERO GENERAL PUBLIC LICENSE) 系列的授權條款（註四），早期 Funambol 計畫（註五）認為 GPL-2.0 的規範有所不足，因此與自由軟體基金會 (Free Software Foundation, FSF) 溝通後取得同意，在原有的 GPL-2.0 中增加了 Section 2(d) 的內容，而在 GPL-2.0 條款的基礎上，以 Affero Inc. 的名義發佈了 AGPL-1.0，其將透過網路使用程式的行為，也納入 AGPL-1.0 條款的拘束範圍之內，其後、更在 2007 年 FSF 釋出 GPL-3.0 之後，改由 FSF 以本身的名義，釋出了 AGPL-3.0（註六）。

而像 CPL-1.0 以及 Eclipse Foundation 專案下採用的 EPL-1.0（註七）也在條款中明文規定，為避免過多授權條款版本而產生不一致的問題，因此這些條款的使用者也無權修改條款文字內容，有權修改者僅為條款中所預先指定者，在 CPL-1.0 是 IBM 以及該公司所指派的條款管理者，在 EPL-1.0 是 Eclipse Foundation 以及該組織所指派的條款管理者。

其他大部分的授權條款（註八），對於他人是否可以修改條款並未有明確的授權表示，但這並不代表使用者可以直接修改。著作權人就一份著作享有獨占排他權利 (all rights reserved)，是目前國際間最常見的著作權保護預設，也就是若沒有清楚的授權許可表示，著作權人原則上保留所有的著作權。因此，在未經明示的狀況下，任何人均不得隨意修改他人釋出條款的內容。而在實務上，就筆者所知，也真有不少未經合法授權而修改使用授權條款的例子，例如將條款當中的準據法或管轄法院修改成適合自己的需求，就是一類較為常見的例子。不過至今尚未聽過有條款著作權人因此而提出侵權主張的個案，最主要的原因，筆者自行推測，應該是提出侵權主張對於條款著作權人並沒有太大的實質意義，再者、公眾授權條款的運用方式本就是全球廣域性的散布，不若一般商業契約是締約雙方私下去擬定，所以若是修改條款內容，但有明確更改條款名稱，或用其他標示方法讓他人不至於誤會衍生的法律文件為原文件的話，那亦不致產生讓他人混淆、誤認原條款授權內容的弊病，所以實務上才沒有產生太大的爭議。

不過以上所提到的討論，都是以授權條款受到著作權法保護為基本前提，而像自由開源授權條款這樣的法律文件是否受到著作權法保護，會因各國規定不同而有所差異。國內的法律架構，許多人認為契約這一類的法律文件並不受到著作權法的保護，但是筆者尚未看到有法律專業文章討論類似的問題。不過，在法律人為事力求謹慎的原則之下，若一份授權條款並未明確表示出使用者可以修改條款內容後再運用，筆者的建議是，盡量是與條款內容的原始著作權人聯繫取得許可之後，再行修改運用，如此才是真正透過互惠尊重的方式，來維持自由開源軟體開發社群能夠良性互動合作的開放態度。

---

註一：AFL-3.0，Academic Free License v3.0；OSL-3.0，Open Software License 3.0；MPL-1.1，Mozilla Public License 1.1。

註二：然而、若是截取 GPL/LGPL 授權條款的文字內容來利用，重新產生另一份「非 GPL 授權條款的法律文件」，則在遵守幾項前提的要求下是可行的，這些前提包括：1、刪除所有 GNU 計畫相關的文字；2、新文件名稱不能再稱為 GPL 或 LGPL 授權條款，避免造成他人誤認此份文件還是 GPL/LGPL 相關的授權文件；3、新文件內容不包含 GPL/LGPL 授權條款的前言。進一步的相關資訊，可參照 GNU 計畫的說明頁面：https://www.gnu.org/licenses/old-licenses/gpl-2.0-faq.html#ModifyGPL。

註三：此兩專案的原始授權方式為 GPL-2.0 + exception，不過在 2007 年自由軟體基金會推出 GPL-3.0 之後，後續版本已改採 GPL-3.0 + exception 的方式進行釋出，進一些的資訊請參見右列頁面：https://www.gnu.org/software/classpath/license.html，https://www.gnu.org/licenses/gcc-exception-faq.html。

註四：AGPL-1.0 的全稱為 Affero General Public License v1，原文內容請參見右列頁面：https://www.affero.org/oagpl.html，AGPL-3.0 改由 FSF 以自身名義公佈，故全稱加上 GNU 為字首，成為 GNU Affero General Public License v3，條款內容請參見右列頁面：https://www.gnu.org/licenses/agpl-3.0.html。

註五：關於 Funambol 計畫的授權說明可參照右列頁面：https://www.forge.funambol.org/learn/licensing.html，目前，其多數的產出元件皆採 AGPL-3.0 與商業授權擇一的雙重授權模式向外釋出。

註六：關於為何要基於 GPL-2.0 來衍生 AGPL-1.0 條款的個中緣由，可參見，葛冬梅，ASP 與自由開源軟體的散布條款，https://www.openfoundry.org/index.php?option=com_content&task=view&id=494&Itemid=56，自由軟體鑄造場電子報第 70 期。

註七：CPL-1.0，Common Public License 1.0；EPL-1.0，Eclipse Public License 1.0。

註八：本文所提及授權條款，若無特別註明，均可至下列網頁中瀏覽其原文內容：https://www.opensource.org/licenses/。