這是本文件的舊版！
授權條款內容的修改
葛冬梅／文 2007-02-09
一般人對於自由開源授權條款的運用，都是原封不動地將條款套用到程式上，不過也有些情況是專案開發者對於程式運用方式有特定想法，此時不見得所有授權條款均可以符合開發者的特定想法，因此就會有修改授權條款的需要。
一份授權條款是否容許他人自行修改後使用，就要看當初草擬條款的著作權人是否授權修改，而是否授權修改可以從看條款本身的規定或者是其著作權聲明中得之。
有些條款在授權文字中即有規定使用者可以修改條款內容，但是修改過條款必須使用與原條款不同的名稱，避免他人與原條款混淆，例如 AFL-3.0、OSL-3.0 與 MPL-1.1 均有類似的規定。
最著名的 GPL-2.0 與 LGPL-2.1 則是在條款一開始之處，透過條款的著作權聲明，明示禁止他人修改條款內容，此外，這兩份條款還規定，任何一位使用者都不可以對程式後續收受者的權利增加任何限制，因此一般人僅可以單純地使用 GPL-2.0/LGPL-2.1 來授權自己的程式，並無法修改條款內容後再來使用（註）。
不過這並不代表完全沒有轉寰之道，GNU 計畫下的一些專案就採用修改過的 GPL 來授權，例如：GNU Classpath 是採用 GPL2+exceptiopn 的方式授權，GNU 計畫之所以可以這樣做，當然是經過 GPL2著作權人 FSF (Free Software Foundation) 的許可。因此，只要經過著作權人同意，一樣可以修改條款內容而後運用。
另外一個例子則是 AGPL，Funambol 計畫覺得 GPL2 的規範有所不足，因此與 FSF 溝通取得同意，在原有 GPL2 中多加了 Section 2(d) 的內容，希望可以將透過網路使用程式的行為也納入條款範圍。
而像 CPL1 以及 Eclipse Foundation 專案下採用的 EPL1 也在條款中明文規定，為避免過多授權條款版本而產生不一致的問題，因此使用者也無權修改條款內容，有權修改者僅為條款中所特定者，在CPL1是IBM以及 該組織所指派的條款管理者，在 EPL1 是 Eclipse Foundation 以及該組織所指派的條款管理者。
其 他大部分的授權條款，對於他人是否可以修改條款並未有任何的授權表示，但這並不代表使用者可以直接修改。著作權人就一份著作享有獨占排 他權利，是目前國際間最常見的著作權保護主義內涵，也就是若沒有授權許可的表示，著作權人原則上保留所有的著作權。因此，在未明示的狀況下，任何人均不得 隨意修改條款內容，若有人如此為之，就是侵權行為。而在實務上，就筆者所知，也真有不少未經合法授權而修改使用授權條款的例子，例如將條款當中的準據法或 管轄法院修改成適合自己的需求，就是一類相當實際的例子。不過至今尚未聽過有條款著作權人因此而提出侵權主張的個案，最主要的原因，筆者自行推測，應該是 提出侵權主張對於條款著作權人並沒有太大的實質意義，若是否允許使用者修改條款是一項重要的考量因素，當初在草擬時，應該就會納入考量並明示寫出來，如同 GPL2、EPL1 一樣。
不過以上所提到的討論，都是以授權條款受到著作權法保護為基本前提，而像自由/ 開放源碼授權條款這樣的法律文件是否受到著作權法保護，會 因各國規定不同有所以差異。在台灣的法律架構下，許多人認為契約這一類的法律文件並不受到著作權法的保護，不過筆者尚未看到有法律專業文章討論類似的問 題，因此對於這個問題的也並未有特定的見解。不過，在法律人謹慎的原則之下，若一份授權條款並未明確表示出使用者可以修改條款內容後再運用，筆者還是建 議，與條款的著作權人連繫取得許可後，再行修改後運用，如此才是真正透過互惠尊重的態度，來維持軟體開發社群長久以來的良好開放態度。
註一：AFL3，Academic Free License 3.0；OSL3，Open Software License 3.0；MPL1.1，Mozilla Public License 1.1。
註二：請參見這裡。
註三：Affero General Public License v.1，原文內容請見這裡。
註四：關於 Funambol 計畫。
註五：其中緣由請參見：葛冬梅，ASP與自由/開放源碼軟體的散布條款 ，開放鑄造場電子報第70期。
註六：CPL1，Common Public License 1.0；EPL1，Eclipse Public License 1.0。
註七：本文所提及授權條款，若無特別註明，均可至下列網頁中瀏覽 原文內容：http://www.opensource.org/licenses/。
