● 相容性：

Q1：甲撰寫的A程式採用一GPL授權的函式庫-Cygwin API Library，並以連結 (link)的方式將該函式庫編入可執行檔中。除了連結Cygwin外，A程式另連結至甲撰寫之另一獨立函式庫B。則 (1) A程式（即最後產出之可執行檔及源碼）是否因使用採GPL授權的Cygwin API Library，而亦須適用GPL？(2) 又甲自行獨立撰寫之函式庫B是否需採GPL授權？

A1：依 GPL(通用公共授權)，其授權條款內容是整體適用於已修改的著作/程式。如著作中可識別之一部份並非衍生自原著作，並得認為係獨立、個別之著作，則使用者將該部分作為個別著作加以散布時，該部分得不適用GPL。若使用者將該部分作為基於原著作所生著作之一部而散布時，則整個著作之散布仍須適用GPL。故：
(1)A程式因靜態連結至採GPL授權的Gygwin API函式庫，故A程式亦須適用GPL。
(2)使用者散布A程式時，若將B函式庫作為A程式之一部而散布，則B函式庫須採GPL；如使用者將B函式庫獨立於A程式之外而個別散布B函式庫，則B函式庫得不適用GPL。

● 軟體之改作：

Q1：為什麼patch不是衍生著作？
A1：衍生著作在著作權法的規範中是指，改作人將他人著作透過翻譯、編曲、改寫、拍攝影片或其他方法就原著作另為創作而產生之著作，因此，衍生著作必然會直接或 間接地包含原始著作的表達。在電腦軟體的著作類型中，程式設計師如果想要直接將他人之程式加以修改或散布修改後之程式，由於修改後程式包含原始程式的部分 內容，將成為原始程式的衍生著作，改作人需要取得原著作權人的改作及散布衍生著作的授權，才能散布修改後之程式。
修正更新檔(patch)是一種引導使用者就特定程式加以修改的小程式，通常較原始程式檔案小得多，因為其中的內容只包含刪除原始程式特定位址及新增程式 碼的指令，並不會將原始程式的內容一併儲存在修正更新檔中。修正更新檔這樣的特殊形式，因為不具有著作權法上衍生著作必然會直接或間接包含原始著作表達的 特性，所以不會被認定為原始程式的衍生著作，而是成為另一個獨立的著作，修正更新檔的作者不僅不需經過原始程式著作權人的授權，並可以獨自選擇授權條款。
在一般人的認知中，常會以為修正更新檔與原始著作具有某一種的關連性，也就是沒有原始著作就不會有修正更新檔，而認為修正更新檔即是原始程式的衍生著作。 然而，修正更新檔不是衍生著作的理由除了因為修正更新檔實際上不會包含原始程式的內容外，另一個理由則是從對原始程式著作權人經濟利益的影響來觀察，著作 權法規定散布衍生著作需要經過原始程式著作權人授權的基礎，主要在於他人將衍生著作散布之後，或多或少都可能影響到原始著作的銷售，為了避免造成原始著作 權人的損失，透過授與原始著作權人散布衍生著作的同意權，而讓其可向衍生著作權人收取權利金。修正更新檔由於實際上不包含原始程式的內容，且一定需要搭配 原始程式才有實質的功能，因此，使用者取得修正更新檔的同時，仍需要透過購買或是其他方式直接向原始程式著作權人取得原始程式的授權，原始程式著作權人並 不會因為他人散布自行開發之修正更新檔而受到經濟利益的損失，此時若仍授與原始著作權人對於散布修正更新檔之同意權，只會造成過高的社會成本，阻礙社會科 技文化的創新。

Q2：在一個作品上做修改、產生衍生著作的行為需要得到原著作的作者同意，那如果 patch 不是衍生著作，產生 patch 就不需要經過原作者同意嗎？
A2： 承接前一個問題的說明，修正更新檔是相對於衍生著作之外的獨立著作，程式設計師開發出一個修正更新檔的同時，只要符合著作權法上對於著作原創性的要求，程 式設計師就創作了一個全新的獨立著作，身為獨立著作的作者，程式設計師並不需要取得任何人的同意便可加以重製散布。
惟另一個需要特別注意的觀念是，開發修正更新檔的程式設計師雖然不需要取得原始程式著作權人的任何授權，但是使用者將一個修正更新檔安裝至原始程式上的同 時，會構成對原始著作的改作行為，應該要取得原始程式著作權人對其程式加以修改的授權，但因為在常用的自由軟體授權契約中皆有授與使用者修改其著作的權 利，因此，使用者仍可以在原始程式授權條款的授權範圍內，安裝修正更新檔。

程式設計師開發修正更新檔雖然可以獨立選擇所欲使用的授權條款，但是考量到使用者安裝修正更新檔構成對原始程式的改作，若修正更新檔採用了與原始著作不相 容的授權條款，將造成使用者無法合法安裝修正更新檔的困境，因此程式設計師需要特別注意其所選擇修正更新檔之授權條款仍必須與原始程式授權條款相容。（相容性的問題請見授權方式選擇（二））

Q3：A 程式是一個利用網路線上多人開發的自由軟體，目前最新的版本是 1.7 版，阿國是後續參與的開發者，想要基於 A 程式 1.7 版之上繼續開發 1.8 版，除了需要得到 A 程式 1.7 版作者的同意之外，還需要得到 1.6 版或更早版本作者的同意嗎？
A3：電腦軟體程式在開發過程中總是會有不同版本的程式釋出，新的版本除非完全捨棄舊有版本的原始碼而另為開發，否則基於舊有版本加以修改而產生的新版本便是前 一版本的衍生著作，此一新版本往往也會採用過去其他舊有版本的程式碼，因此，一個新版的程式不僅僅是其前一版本的衍生著作，同時也會是過去其他舊有版本的 衍生著作。
新版本程式可能同時是其前一版本與其他舊有版本的衍生著作，如此一來，阿國如果想要承續 A 程式 1.7 版加以修改開發 1.8 版，阿國所開發的 A 程式 1.8 版將成為 1.7 版的衍生著作，同時也是 A 程式先前其他版本的衍生著作，阿國除了要取得 A 程式 1.7 版開發團隊的改作授權之外，同樣也需要取得過去舊有版本開發團隊的授權才能進行 1.8 版的改作。
網路線上多人開發是目前自由軟體常見的開發模式，但這種開發環境卻容易造成著作權人間的法律關係過於複雜，以阿國的例子來說，A程式是網路線上多人開發的 自由軟體，因此，打從A程式1.0到1.7版多個版本之間的著作權人分別是誰，以及阿國要如何向成千上萬的開發團隊取得授權，都是一個非常複雜與難解的法 律問題，此時就必須仰賴自由軟體專案開發者在程式開發之初，事先妥善規劃完善的授權條款，才不會因此形成後續開發者的難題。(例如：GPL ( General Public License )與MPL ( Mozilla Public License )這兩種自由軟體授權條款，因為在授權契約中約定該著作其後所生之任何衍生著作，皆必須採用相同的授權方式。因此，採用此類授權條款的程式，在各種釋出版 本間皆能維持一致的授權方式，可以降低並簡化後續開發者取得授權的困難。)

Q4：曉玲在進行 A 程式的開發過程中，向好友順子取得了一份他經常使用的 B 程式碼複本 ，B 程式的作者雖然是曉玲與順子素未謀面的阿東，但 B 程式卻是以自由軟體模式授權，如果曉玲想要以 B 程式作為開發 A 程式的基礎，需要得到順子的授權還是 B 程式作者阿東的授權？
A4：在通常的情形下，順子雖然是將 B 程式提供給曉玲的人，但因為順子並非 B 程式的著作權人，因此曉玲還是需要直接向 B 程式的著作權人阿東取得重製或改作的授權後，才能進一步地利用 B 程式。不過由於阿東的 B 程式是採用自由軟體的模式授權給不特定的使用者（包括曉玲在內），因此曉玲只要遵守 B 程式的授權條款約定，就可以對 B 程式做重製或改作。
少數的自由軟體授權條款，例如：MIT、MPL ( Mozilla Public License )及CPL ( Common Public License )授權條款，訂有允許他人以自己名義將該軟體"再授權(sublicense)"給第三人之約定。如果阿東採取的是前述三種授權條款，則表示阿東允許順子 在符合原授權條款的約定下，以順子自己為授權人，在阿東所授權給她的範圍內再授權給曉玲，授權契約的當事人便是曉玲與順子。這種"再授權"的情況下，對於 被授權的曉玲來說一樣可以取得有效的重製或改作授權，差別僅在於授權人是被授權可為再授權的順子，而非原程式著作權人阿東。
一般來說，會特別需要採行"再授權"的情形，較多發生在第三方程式開發公司在將 B 程式加以商業化販售時， B 程式購買者如果要求和該公司直接訂立授權契約，第三方公司在遵守原授權條款再授權的約定下，便能以自己為授權人和購買者訂約。不過允許第三人可再授權的自 由軟體授權條款並不多，因此，在與商業公司簽訂授權契約時，被授權人必須特別注意 B 程式原本之授權條款中是否有允許商業公司"再授權"之約定，否則，縱使和商業公司簽訂了授權契約，但欠缺原程式著作權人阿東的"再授權"約定，被授權人仍 然無法合法地利用 B 程式。

● 授權方式選擇：

Q1：我喜歡一授權方式（如 QPL）的設計，但是覺得其中某些條款並不適合我的需求，若我把這些不適合的條款拿掉，是否仍然可以宣稱我選擇的是這個條款（如 QPL）嗎？
A1：不可以
授權契約雖然是作者與使用其著作者間的契約關係，其授權契約內容可以由作者本人決定，作者可以選擇某種常用的授權方式，或者另外與使用者訂定內容不同的授權契約，只要作者與使用者之間可以達成此一著作使用方式的合意，雙方之間的授權契約便可成立。
但若作者認為某一常用的授權方式 A 是他比較喜歡的，但是覺得其中部分條文並不十分適用於此一著作的情況，此時，作者可將這個授權方式 A 作為範本，再作增刪、修改。但一旦有所增刪修改，則作者已經產生了一個與原授權方式 A 不同的授權契約 B 。此時作者不能宣稱他所選擇的是 A 授權條款，特別是在常用的授權方式的情形，若作者持續聲稱他所選擇的是 A 授權條款，則容易使自由軟體不易特定的潛在使用者們誤以為作者使用的就是 A 授權條款，而無法認知到作者所授權他人所使用的方式是與 A 授權條款的內容有所不同，致使雙方對於授權契約有不同的理解、甚至導致爭議的產生。

Q2：小凸的專案使用了 A、B、C 三種不同模組，且 A、B、C 各自是用A'、B'、C'三種條款授權，小凸可以將整個專案包裝起來後選擇 A 或 B 或 C 或其他方式授權嗎？
A2：小凸使用兩種以上且分別採用不同授權條款的模組所據以開發的軟體專案，最後他是否可以統一以單一模式的授權條款釋出，依照不同模組間相互結合的程度，而有不同的處理方式。
如果小凸是以 A、B、C 未經修改的形式，讓程式之間彼此溝通、運作，則小凸對於 A、B、C 的關係，是"使用他人著作"的行為，在著作權法上，是"再散布"他人著作的意義。基於對他人創作的尊重，A、B、C的原始著作權人既然已經為他的著作選擇 某種授權方式，小凸當然必需加以遵循，因此專案中的 A、B、C 仍需分別依 A'、B'、C' 授權。
不過在軟體開發過程當中，免不了會對於其中使用到的模組加以修改，例如小凸將 A 模組與 B 模組整合成為 X 模組，X 是改作 A 與 B 而來，在著作權法的意義上，X 既是 A 的衍生著作，同時也是 B 的"衍生著作"，小凸除了必需確保他獲得 A 與 B 原始著作人的改作授權外（自由軟體的授權條款中已授權使用者得對著作加以修改），A 與 B 得否相互整合，還必需看看 A 與 B 的授權條款 A' 與 B' 是否相容。簡單來說，如果 A' 與 B' 對於衍生著作的相關規定均不相互衝突（如 A' 並沒有限制 A 不得與採 B' 授權條款的 B 模組相互整合，B' 亦無阻礙 B 與 採用 A' 的 A 模組相互整合的規定），則由於 A' 與 B' 具有相容性，使得 A 與 B 得相互整合成為 X，此時小凸就可以著作權人之地位，為 X 選擇授權條款，他可以選擇 A'、B' 或與 A'、B' 相容之其他授權條款。在小凸使用三種以上模組進行開發的情形，亦可參考以上的說明。
所以，小凸如果修改 A、B、C 三個模組而將其整合成為 D 模組的情形下，只有當授權條款 A'、B'、C'經過判斷具有相容性，他才可能讓整個專案以單一模式 A' 或 B' 或 C' 或與 A、B、C 均相容的 D' 進行授權。
因為自由軟體授權條款種類很多，彼此之間相容性問題的判斷，涉及不同授權條款所使用的文字在法律意義上的解讀，小凸最好進一步尋求對於著作權法及自由軟體授權條款有研究的專業人士之協助。

Q3：凱莉僅將 B 程式的部分程式碼加入她自己所開發的 A 程式，需要經過 B 程式的作者授權嗎？如果 B 程式的授權條款與凱莉原本為 A 程式所選擇的授權條款不同，結合之後的程式應選擇哪一種授權條款？
A3：程式設計師在軟體開發的過程當中常常會使用到他人所開發出來的程式，不論是使用全部或一部，基於對他人創作的尊重，原則上都必需獲得原始著作權人的授權， 至於授權的內容是重製權或改作權，則要看凱莉怎麼利用 B 程式。如果凱莉並未對 B 程式加以修改，而只是複製全部或部分之程式碼，則她取得重製 B 程式之授權即可；如果凱莉是對於 B 程式全部或部分的程式碼加以修改後再加到 A 程式中，則還需另外取得 B 程式改作的同意。使用自由軟體的好處是，其授權條款都有規定使用者可以對於該著作加以重製及修改，因此在遵守授權條款的前提下，凱莉不必擔心是否未經取得 合法授權而造成侵害著作權的情形發生。
凱莉將他人的 B 程式與自己開發的 A 程式整合在一起，假設整合後的程式為 C，由於 A、B 原先所採取的授權條款 A' 與 B' 並不相同，因此必需注意相容性的問題，如果 A' 與 B' 經過判斷不具相容性，則 A 與 B 無法合法整合成為 C；如果 A' 與 B' 具有相容性，才有授權條款選擇的問題產生，此時，C 的授權條款可以是 A' 或 B' 或任何與 A' 及 B' 均相容的 C'。（相容性的說明，請參考授權方式選擇（二））

Q4：所有的自由軟體授權條款都有免除責任聲明，阿海的專案中使用了分別採用 A'、B'、C' 等自由軟體授權方式的 A、B、C 三個模組，並選擇 D' 為整個專案的授權方式，但是 A' 與 D' 並不相容，因此阿海以 D' 授權方式釋出整個專案的行為會違反 A 作者與阿海之間的授權契約，阿海可以 D' 之中的免責條款對 A 的作者主張免責嗎？
A4：不可以。
因為自由軟體允許他人自由地重製、修改以及散布其原始碼，對於由經過修改的程式碼之瑕疵所造成的損害，要求原始著作人負責，並不合理，再者，法律上責任的 承擔必需要有相當的報酬作為對價，由於自由軟體通常是無償地授權他人使用，因此在所有的自由軟體授權條款中幾乎都有免除責任聲明的約定，以鼓勵公開原始 碼。所以常見的免責條款，通常包括以下規定：「除非依相關法律或書面協議之要求，任何著作權人或任何依本授權條款為改作或散布程式之人，均不對您的損失負 有任何法律責任。」這裡的「您」指的是該自由軟體的使用者。由於 D' 與 A' 並不相容，阿海並不能選擇 D' 作為整個專案的授權條款。（相容性說明，請參考Q7）阿海的 D 程式中使用了 A 程式，但未遵守 A'，而為 D 選擇了與 A' 不相容的 D'，是違反他與 A 程式作者間的授權契約，D' 中對 D 程式使用者所約定的免責條款，因此阿海不能以 D' 當中的免責條款，而對 A 作者主張免除違反 A 程式授權條款的責任。

Q5：小張開發出來的程式已經採用自由軟體模式授權，但有個商業公司對小張開發出來的程式非常有興趣，小張可以再和他們談另一種商業性的授權契約嗎（如約定可以向他們收取權利金等）？
A5：可以。
對於小張自己所開發出來的程式而言，小張是這個程式的著作權人，因此他便得以著作權人的身份，授權其他人使用他所開發出來的程式。此種授權契約是私法性質 的契約，因此小張只要達成他和被授權人之間的合意，就可以成立。小張和不同的人，可以就不同的情況、不同的需求，談出不同內容的授權契約。
小張自己所開發的程式雖然已經以自由軟體模式進行授權了，但是若這個程式十分好用，而有廠商希望小張能夠授權給他們，作商業性的利用，此時身為著作權人， 小張是有權利作這種多重授權的。但是基於民事法上的誠信原則、並避免無謂的糾紛，小張最好還是確保廠商有明白地了解到小張的軟體原本已採用何種自由軟體模 式的授權。
但必須注意的是，若小張在開發這個程式時，曾經使用了既有的自由軟體模組，由於既有模組的授權條款可能拘束小張所改作之作品的授權方式，則小張在授權其他 人利用他的著作時，必須確保這種授權方式與被他所使用的既有模組的授權方式彼此之間是相容的，而且小張自己的確是有權利作這樣的授權的。亦即，除了在小張 自己獨力開發、並未借重既有模組的情形，小張可以自由地選擇自己作品的授權方式之外；在小張使用了既有模組的情況之下，小張的程式授權方式選擇必須取得該 模組原作者的同意（在某些授權條款如 MIT 等，模組的原作者可能允許其他人為他修改後的版本選擇自己喜歡的授權方式，這也可以算是已經取得原作者的同意）。 （相容性的問題請見授權條款選擇（二））
另外，除非此商業性的授權契約是專屬授權的情形，小張也可以一開始就為他的軟體做自由軟體和商業性兩種不同的授權，這是著作權法賦予作者的權利。但同樣是 基於民事法上的誠信原則，小張必須在與廠商洽談交易內容時，就讓廠商明白了解到小張的軟體另外有採用何種自由軟體模式的授權，以讓廠商充分明白此一軟體允 許一般大眾作何種形式的利用，並決定雙方的授權契約要達成何種內容的合議。
事實上不管是小張一開始就為他的軟體同時作自由軟體和商業性兩種不同的授權，或只作自由軟體模式的授權，後來跟廠商洽談商業模式的授權（或先商業再開 放），小張將軟體授權的模式與種類充分告知廠商，還可能進一步與廠商充分合作，就軟體的市場定位、行銷方式進行討論，並可避免廠商因為不知軟體有另外的開 放性授權、進而錯估市場情勢，而造成意料之外的損失。

本文原始連結：http://www.openfoundry.org/article.pl?sid=04/11/10/079203&mode=thread&