差異處

這裏顯示兩個版本的差異處。

--- essays_and_articles:openfoundry_legal_column_selected_collections_2011:授權條款內容的修改 [2012/02/07 06:44] – lucien
+++ essays_and_articles:openfoundry_legal_column_selected_collections_2011:授權條款內容的修改 [2026/03/06 16:38] (目前版本) – 外部編輯 127.0.0.1
@@ 行 1: / 行 1: @@
-授權條款內容的修改
+**授權條款內容的修改**
-葛冬梅／文 2007-02-09
+葛冬梅、林誠夏／文 2007-02-09 發布 2012-02-08 修改
 一般人對於自由開源授權條款的運用，都是原封不動地將條款套用到程式上，不過也有些情況是專案開發者對於程式運用方式有特定想法，此時不見得所有授權條款均可以符合開發者的特定想法，因此就會有修改授權條款的需要。
@@ 行 13: / 行 13: @@
 不過這並不代表完全沒有轉寰之道，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（註六）。
+另外一個例子則是 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 以及該組織所指派的條款管理者。
@@ 行 19: / 行 19: @@
 其他大部分的授權條款（註八），對於他人是否可以修改條款並未有明確的授權表示，但這並不代表使用者可以直接修改。著作權人就一份著作享有獨占排他權利 (all rights reserved)，是目前國際間最常見的著作權保護預設，也就是若沒有清楚的授權許可表示，著作權人原則上保留所有的著作權。因此，在未經明示的狀況下，任何人均不得隨意修改他人釋出條款的內容。而在實務上，就筆者所知，也真有不少未經合法授權而修改使用授權條款的例子，例如將條款當中的準據法或管轄法院修改成適合自己的需求，就是一類較為常見的例子。不過至今尚未聽過有條款著作權人因此而提出侵權主張的個案，最主要的原因，筆者自行推測，應該是提出侵權主張對於條款著作權人並沒有太大的實質意義，再者、公眾授權條款的運用方式本就是全球廣域性的散布，不若一般商業契約是締約雙方私下去擬定，所以若是修改條款內容，但有明確更改條款名稱，或用其他標示方法讓他人不至於誤會衍生的法律文件為原文件的話，那亦不致產生讓他人混淆、誤認原條款授權內容的弊病，所以實務上才沒有產生太大的爭議。
-不過以上所提到的討論，都是以授權條款受到著作權法保護為基本前提，而像自由開源授權條款這樣的法律文件是否受到著作權法保護，會因各國規定不同而有所差異。國內的法律架構，許多人認為契約這一類的法律文件並不受到著作權法的保護，不過筆者尚未看到有法律專業文章討論類似的問題。不過，在法律人為事力求謹慎的原則之下，若一份授權條款並未明確表示出使用者可以修改條款內容後再運用，筆者的建議是，盡量是與條款內容的原始著作權人聯繫取得許可之後，再行修改運用，如此才是真正透過互惠尊重的方式，來維持自由開源軟體開發社群能夠良性互動合作的開放態度。
+不過以上所提到的討論，都是以授權條款受到著作權法保護為基本前提，而像自由開源授權條款這樣的法律文件是否受到著作權法保護，會因各國規定不同而有所差異。國內的法律架構，許多人認為契約這一類的法律文件並不受到著作權法的保護，但是筆者尚未看到有法律專業文章討論類似的問題。不過，在法律人為事力求謹慎的原則之下，若一份授權條款並未明確表示出使用者可以修改條款內容後再運用，筆者的建議是，盡量是與條款內容的原始著作權人聯繫取得許可之後，再行修改運用，如此才是真正透過互惠尊重的方式，來維持自由開源軟體開發社群能夠良性互動合作的開放態度。
 ----