問題 1  哪些不同的授權條款的程式碼是不能一同抄寫在一起的呢？

原則上，只要是 Copyleft 性質的授權條款，它的程式碼就不能與其他同屬 Copyleft 類別的程式碼抄寫在一起。（關於 Copyleft 性質的說明，請見問題 7。）

具有 Copyleft 性質的授權條款主要是 GPL 類，而 MPL、CDDL、EPL 與 CPL 也具有部份 Copyleft 性質，因此，原則上任一 GPL 類的程式碼都不能和另一類 GPL 類的程式碼抄在一起，例如 GPL-2.0 程式碼不能與 GPL-3.0 程式碼抄寫在一起，而只能去抄 BSD、MIT 授權的程式碼，然後最後整個作品的授權條款改為 GPL-2.0 授權。（常見的授權條款分類請見問題 8。）

不過這樣的原則仍有例外，例如 GPL-2.0 與 LGPL-2.1 間特別規定有相容的轉換條款，LGPL-2.1 程式碼可以單向地改採 GPL-2.0 授權，透過轉換條款，LGPL-2.1 與 GPL-2.0 並不相衝突；另外 MPL-1.1 第 13 條明示多重授權機制，讓使用者在利用與散布特定 MPL-1.1 程式碼的時候，可以有機會改採其他的條款來授權這些特定的 MPL-1.1 程式碼。

若是您所利用的自由開源軟體授權條款多樣、複雜的話，建議您尋求專家的諮詢，以確認這些授權條款彼此相容。

此外，您也可以參考自由軟體基金會 (Free Software Foundation, FSF) 的授權條款列表與說明，來了解哪些自由開源軟體授權條款程式碼適合與 GPL、LGPL 程式碼寫在一起：https://www.gnu.org/licenses/license-list.html

問題 2   使用他人自由開源軟體授權的程式，著作權聲明該如何標示？

著作權聲明的標示並沒有一定的制式格式，只要使用者可以容易看到，並且內容清楚易懂即可。您可以寫個獨立的文字檔案來說明您的著作權與授權內容，並讓這個文字檔隨著自由開源軟體一起散布；若是您的軟體有圖形化介面(GUI)的話，則可以將這些文字內容放在『關於(About)』中。

若是您的開源軟體是修改自他人的自由軟體而來，請在標示著作權的時候，也將他人的自由開源軟體相關資訊也標示出來，以彰顯其他自由開源軟體開發者與著作權人的聲譽。

1. 宣告授權條款的方式：https://www.openfoundry.org/for-developers/1884-2010-07-13-09-48-09
2. 修改自由軟體的著作權人標示：https://www.openfoundry.org/tw/legal-column/1747-2010-07-15-10-26-14
3. 內含 GPL 授權元件產品的標示義務：https://www.openfoundry.org/tw/legal-column-list/2384

問題 3  什麼是自由軟體 (Free Software)？

嚴格來說，自由軟體 (Free Software) 是指符合自由軟體基金會 (Free Software Foundation, FSF) 所定義的四大自由內涵的軟體，與開放源碼軟體 (Open Source Software) 並不相同。由於一個軟體是否符合四大自由取決於授權條款的內容，因此自由軟體基金會在其網站上列有符合四大自由的授權條款清單。

問題 4   什麼是開放源碼軟體 (Open Source Software)？與自由軟體有什麼差別？

開放源碼軟體，中文也有翻譯為開源軟體或開放原始碼軟體，是指採用開放源碼授權條款來散布授權的軟體。而所謂開放源碼授權條款，是指通過「開放源碼促進會」(Open Source Initiative, OSI ) 審查，符合開放源碼定義 (Open Source Definition, OSD) 的授權條款。由於英文中的 "free" 會引發使用者誤解自由軟體是免費的軟體，間接阻礙自由軟體的商業發展，因此開放源碼促進會改採用「開放源碼」(Open Source)一詞，希望避免誤解，進而促進自由軟體的商業發展。因此嚴格來說，自由軟體與開放源碼軟體是兩種定義不同的軟體，其背後所想要達到的目的也不相同，不過由於這兩種軟體有著許多共通點，因此若是不加以深究的話，可以簡單地將兩者視為同一種類的軟體。

問題 5   什麼是「免費軟體」(Freeware)？與自由開源軟體有什麼差別？

Freeware，英文中所使用的 Free 指的是「免費」的意思，中文常翻作「免費軟體」，這類的軟體簡單來說就是 "Free-downloaded Software"，使用者可以免費下載這樣的軟體，但不見得可以取得程式的原始碼。此外，免費軟體的著作權利人還是保有其著作權利，所以雖然可以免費下載，但要看下載者的立場來判定是否合法使用，部份的免費軟體是允許使用者做任何方式的利用，即使使用者是公司也一樣，但也有很大部份的免費軟體，是限定只讓終端使用者 「個人免費使用」(End-user only)。

問題 6  什麼是「共享軟體」(Shareware)？與自由軟體有什麼差別？

Shareware，中文常翻作「共享軟體」，這類的軟體可以說就是「進階版的Freeware」，使用者可以免費下載共享軟體來使用，但軟體使用上可能有附帶限制，例如使用時間受限，使用者只能使用30天，30天後若不付費的話就必須停止使用；又例如免費的版本只提供部份功能，付費後使用者才會得到程式完整功能的使用權。此外，使用者也無法拿到共享軟體程式的原始碼。

問題 7  什麼是“Copyleft ”？

"Copyleft" 一詞由史托曼 (Richard M. Stallman) 首先提出，乃是針對「著作權」的英文 "Copyright"而新造的詞，用來代表一種與過往常見的程式授權方式相反的新授權機制，以防止程式源碼被封閉起來，而導致程式無法再被改進。 Copyleft機制建立在承認程式受到著作權保護的基礎之上，預先將複製 與修改程式等著作權的權利授權出去，讓使用者在拿到程式的同時就可合法複製與修改程式，此外，當使用者在散布程式的時候，也必須要讓後手擁有複製與 修改程式的權利。由於過往常見的程式授權方式並沒有將複製與修改程式的權利預先授予使用者，使用者通常僅可以執行程式，因此 Copyleft 與過往常見的程式授權方式大相逕庭。

目前 Copyleft 並沒有一個明確的定義，但是依據史托曼的著作 "What is Copyleft?"，可以歸納出 Copyleft 主要具有三項特性：(1) 以實現程式使用者的四大自由為目的；(2) 將複製與修改程式碼的權利預先授權出去；(3) 散布程式碼的同時仍必須採用相同方式來授權。

1. Copyleft〈公共版權〉：https://www.openfoundry.org/tw/glossary/736-copyleft
2. What is Copyleft?：https://www.gnu.org/copyleft/

問題 8  自由軟體授權條款可以如何分類？

自由開源軟體授權條款依照不同的標準，可以有不同的分類方法。為了方便分析自由開源軟體授權條款之間的相容性，因此 OSSF 將授權條款分為下列三類：GPL 類、BSD 類與其他類：GPL 類授權條款對於衍生著作的拘束性較強，大多數的情況下，衍生著作仍然必須採用原來相同的條款繼續授權；BSD類條款則對於衍生著作權的授權內容幾乎沒有拘束；而其他類條款對於衍生著作權授權內容的拘束性則介於中間，原則上必須採用原來相同的條款繼續授權，但是例外狀況可以採用其他的條款來授權。

常見的授權條款分類請見下表：「常見自由開源軟體授權條款分類表」。

問題 9  自由開源軟體授權條款「不得收取授權金」的原則，是什麼意思？

自由開源軟體授權原則上是以「不收取」著作權權利金、專利權權利金的方式進行散布，這是因為授權金的收取方式，向來有「授權對象、授權地域、授權期間」的限制，這些限制與自由開源軟體允許使用者自行修改、自行重製散布的模式有衝突，所以不得以收取授權金的方式來運作。不過在實際應用上，有些收費模式並不違背這項原則，例如雙重授權模式，這時候就會看到收取授權金的例外與不收取授權金的原則並存而行。關於雙重授權模式，請參見問題 10。

需注意的是，自由開源軟體的商標權授權金是可以收取的，因為商標權是以圖標、圖形 (mark, logo) 的方式來顯現，這些圖標、圖形是可以被使用者自行移除掉的，只要自行移除掉，就不會有商標授權方面的問題。使用上若不欲支付商標授權金給商業公司，需注意：(1) 不拿商標本身與此商標有關的字樣來為商業服務廣告宣傳，僅能事實性的標註該專案的利用狀態；(2) 產品在散布時，移除掉商標的圖標及圖形。若不能達致上述兩種方法，並涉及商業利用的話，那麼就必須另行與商業公司洽談取得該商標的書面授權。

問題 10   自由開源軟體授權條款「不得收取授權金」的原則，是否允許例外？

實務上「雙重授權」的做法可以達到收取授權金的目的，而同時又不會影響自由開源軟體不收取著作權與專利權授權金的原則。例如 Oracle MySQL 資料庫同時以商業授權及 GPL-2.0 的方式併行釋出，所以如果使用者選擇以 GPL-2.0 的方式取得 Oracle MySQL 資料庫，便可以不用支付授權金給 Oracle，唯後續對此資料庫軟體的修改與散布，都必須依照 GPL-2.0 的授權規則來進行；但如果使用者選擇以商業授權的方式取得 Oracle MySQL 資料庫，那麼就必須支付一筆授權金給 Oracle，來取得商業授權的 MySQL 版本，但其後對該資料庫軟體的應用，則悉依商業授權的規範，而不需再受到 GPL-2.0 的約束。

不過要注意的是，必須所有自由開源軟體的著作權人均同意，才可以進行這樣的雙重授權。若是軟體中包含軟體專利的話，也一樣必須要取得所有專利權人的同意，方得進行。

問題 1  關於軟體專利的授權，請問GPL有無規範？

GPL-2.0究竟有無明定「軟體專利授權」存在著爭議，有人認為有，有人認為沒有。認為 GPL-2.0 已明訂軟體專利授權條款的人，主要根據來自第7條：任一 GPL-2.0 授權的程式一經散布之後，就必須完全依照 GPL-2.0 的規則來提供修改、應用、重製與散布，即使上面有經司法訴訟判定的軟體專利權利，亦同，若不能做到這點，散布者就不得散布這個 GPL-2.0 授權的程式。

然而，部分論者認為GPL-2.0 第7條僅在表達一種態度，而未明文處理軟體專利授權議題，因為第7條確實從頭到尾並無明示「依據 GPL-2.0 取得程式著作權授權之人，一併取得其軟體專利的使用授權。」那麼，依照各國著作權法，著作財產權授權約定不明的部分，多推定為未授權；而專利權的授權方面，慣性上也多以明示的書面授權文件為準，所以推論上，並沒有強而有力的具體根據，認為僅依GPL-2.0第7條的規定，就認定該條款規範了明確的專利授權機制。GPL改版至3.0時，處理了這個議題，其明文規範依據 GPL-3.0 取得程式著作權授權之人，一併取得其軟體專利的使用授權。自此之後，採GPL-3.0 授權的元件，軟體專利有無隨同授權的爭議已不復存在，然GPL-2.0關於此議題，還存有懸而難解的灰色地帶。

關於GPL-2.0第7條的推論與說法的進一步說明，可以參照葛冬梅小姐與林誠夏先生合寫的「GPL-2.0 第 7 條淺評」的短篇專文 

問題 2  （承上）GPL若有關於軟體專利授權的規範，有無區分「衍生程式的專利」和「獨立程式的專利」？

所謂獨立程式，依照一般通說，指的是其並非參考GPL程式來撰寫，該程式也可以被其他程式呼叫，或呼叫其他程式；而其與GPL程式的結合，只是置於同一個專案裡去進行功能上分工，這種狀態的話，該程式的授權狀態未必直接受到 GPL 程式的影響。

因此，一般來說，個別元件被判定為「獨立程式」的話，不論是GPL-2.0或GPL-3.0的所有授權規則都不會過渡到其上。所以依照這樣的論述，在一個大型軟體專案裡，「GPL 元件衍生程式的專利」與「GPL 元件獨立程式的專利」是有分立與分別主張的機會的。
 

問題 3  我使用 Java 開發了一個資料存取軟體（暫稱為 A 軟體），而A軟體在執行時會使用到 GPL 授權的程式，但會由客戶自行安裝及設定，請問這種情況下，我所開發的 A 軟體會否受到 GPL 感染？

如果你在安裝程式的流程裡，讓客戶可自行閱讀軟體的授權聲明，並自行進行這些 GPL 授權元件的安裝，那麼可以視為客戶自行下載取得這些 GPL 授權元件，而有機會可解釋為「自由開源軟體分開下載、自行安裝 」的區隔方式。因為這樣的方式是將程式與程式間結合的責任轉嫁給客戶，所以受到 GPL 拘束的主體就變成該名自行安裝 GPL 程式的客戶，實務上、只要該客戶不再散布這個組合過的系統，就不會產生 GPL 授權程式散布後要再提供原始碼給後手的問題，但前提是、客戶需要充份認知到這個事實並且也同意，先期溝通清楚，這樣可以降低日後很多的爭議或是糾紛。

不過，如果你是打包成一整個 PACKAGE，可透過「機械化的自動方式」來安裝，那麼多數的見解是這樣的運用方式仍會開啟 GPL 的授權拘束性。

關於這方面的資訊，您可以參考下列文章來進一步了解相關內容：GPL 的另類利用方式：「分開散布．責任轉嫁」。 

A1：不可以。授權條款是作者（即授權人）與使用其著作者（即被授權人）間的契約，授權契約內容可以由作者本人決定。作者可以選擇某種常用的授權條款（如 GPL），或者另外與使用者訂定不同於常用授權條款的授權契約，只要作者與使用者達成對此一著作使用方式的合意，雙方之間的授權契約便可成立。
但像林正國雖然較喜歡某一常用的 X 授權條款，但是其中部分條文並不十分適用於此一著作時，他可拿 X 授權條款內容作為範本，再行增刪、修改，另產生一新的 Y 授權契約。但一旦有所增刪修改，林正國就不能宣稱他所選擇的仍是 X 授權條款，因為這樣會使其他使用者誤以為林正國使用的是原本的 X 授權條款，而無法認知林正國授權他人使用的方式不同於 X 授權條款，致使雙方對於授權條款產生不同的理解、甚至導致爭議的產生。

Q2：林正國欲將 A 模組 (module) 與 B 模組修改成為 C 模組，而 A、B 模組分別使用 X、Y 授權條款，林正國可以這麼做嗎？又林正國可以選擇 X、Y 或與 X、Y 授權條款相容之其他授權條款釋出 C 模組嗎？若 X、Y 授權條款不相容又應如何處理？

A2：視所選擇的授權條款是否相容而定。林正國若將 A 模組與 B 模組修改為 C 模組，C 模組是改作 A、B 兩模組而來，在著作權法的意義上，C 模組同時是 A 模組與 B 模組的衍生著作，林正國除了必須分別獲得 A、B 兩模組原始著作權人的改作授權外，A、B 兩模組得否整合成一模組，還須看 A、B 兩模組分別適用的 X、Y 授權條款是否相容。

如果 X、Y 授權條款對於衍生著作的相關規定不相衝突（如 X 授權條款不限制 A 模組不得與採用 Y 授權條款的 B 模組相整合；Y 授權條款亦無阻礙B模組與採用 X 授權條款的 A 模組相整合的規定），由於 X、Y 授權條款具相容性，A、B 模組得整合成為 C 模組，林正國得以 C 模組著作權人之地位，選擇 X 或 Y 授權條款或與 X、Y 授權條款相容之其他授權條款釋出 C 模組。

但如果 X 和 Y 授權條款不相容，例如 X 授權條款規定在散布程式碼時必須同時釋出原始碼，而 Y 授權條款無此規定；且 X 授權條款規定不能做商業目的使用，而 Y 授權條款無此規定，但林正國依然將 A 和 B 模組整合成 C 模組，此時可能需採用較嚴格的 X 授權條款，或另外尋找適合的 Z 授權條款。

自由軟體授權條款種類眾多，彼此之間相容性的判斷，涉及不同授權條款使用的文字在法律意義上的解讀，林正國最好進一步尋求對著作權法及自由軟體授權條款有研究的專業人士之協助。

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

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

Q4：(1) 林正國將 B 程式的部分程式碼加入他所開發的 A 程式中，需要經過 B 程式作者陳凱莉授權嗎？(2) 如果 B 程式所適用的授權條款為 Y，而林正國為 A 程式所選擇的授權條款為 X，則 A、B 兩程式結合而成的 C 程式應選擇哪一種授權條款？

A4：(1) 林正國欲將陳凱莉開發的 B 程式的部分程式碼加入他所開發的 A 程式中須經陳凱莉授權；何種授權則視林正國的行為而定。

如果林正國未修改 B 程式，只是複製全部或部分 B 程式碼，則他取得重製 B 程式之授權即可；如果林正國修改 B 程式全部或一部後，再加到 A 程式中，則他需取得改作 B 程式之授權；如果林正國複製或修改 B 程式全部或一部，並加入 A 程式中，之後欲對 A 程式加以散布，那麼，林正國除取得改作 B 程式之授權外，另須取得散布 B 程式的授權。

程式開發者在軟體開發的過程當中常會使用到他人開發的程式，不論使用全部或一部，基於對他人創作的尊重，原則上都必須獲得原始著作權人的授權。至於授權內容是重製權、改作權或散布權，要看該程式開發者如何利用他人的程式。

多數自由軟體授權條款皆規定使用者可以重製、修改並散布程式開發者所開發之原始著作，只要確實遵守授權條款的規定，使用者不必擔心會有著作權侵害的問題。

(2) 林正國將其開發的 A 程式與陳凱莉的 B 程式整合成 C 程式，又 A、B 程式分別採用 X、Y 授權條款，如果 X、Y 兩授權條款不相容，則 A、B 程式即無法合法整合成為 C 程式，林正國必須針對不相容的部份尋找可能的其他授權條款，並進一步諮詢對著作權法及自由軟體授權條款有研究的專業人士。如果 X、Y 授權條款具相容性，則 C 程式可適用 X 授權條款或 Y 授權條款或任一與 X 及 Y 授權條款均相容的授權條款。（相容性的說明，請參考 Q2、Q3）

Q5：陳凱莉的甲專案中使用了分別採用 X、Y、Z 授權條款的 A、B、C 三模組，並選擇 W 授權條款釋出甲專案，但 X 與 W 授權條款並不相容，試問： (1) 陳凱莉以 W 授權條款釋出甲專案會否違反 A 模組作者林正國與陳凱莉間的授權條款？(2) 又陳凱莉可以 W 授權條款中的免責條款對林正國主張免責嗎？

A5：(1) 陳凱莉的行為違反了其與林正國間成立之授權條款。由於 W 與 X 授權條款並不相容，陳凱莉的甲專案中使用了 A 模組，但卻未遵守 X 授權條款，卻選擇與 X 授權條款不相容的 W 授權條款釋出甲專案，故陳凱莉此行為會違反其與林正國間成立之的 X 授權條款。

(2) 陳凱莉不能以 W 授權條款中的免責條款，對林正國主張免除其違反 X 授權條款的責任，因為 W 授權條款中的免責條款規範的是甲專案使用者與開發者（即陳凱莉）間的關係，而不是甲專案開發者（即陳凱莉）與甲專案中所使用的程式所有人／開發者（即林正國）間的關係。【按】：自由軟體允許他人自由地重製、改作以及散布其原始碼，經過修改的程式碼之瑕疵所造成的損害，要求原始著作人負責並不合理；再者，法律上責任的承擔必須有相當的報酬作為對價，而自由軟體通常都是無償地授權他人使用。因此，幾乎所有的自由軟體授權條款中都有免除責任聲明，以鼓勵公開原始碼。常見的自由軟體授權條款中的免責條款，通常包括以下規定：「除非依相關法律或書面協議之要求，任何著作權人或任何依本授權條款為改作或散布程式之人，均不對您的損失負任何法律責任。」（這裡的「您」指的是該自由軟體的使用者。）

Q6：(1) 林正國開發出來的 A 程式採用自由軟體模式授權，有商業公司對 A 程式有興趣，林正國可以再和這家公司談商業性授權嗎（如約定林正國可向這 家公司收取權利金等）？(2) 若 A 程式不完全是林正國所開發，在開發的過程中，林正國使用了他人既有的 B 模組，而 B 模組使用 Y 自由軟體授權條款，A 程式開發完成後同樣採用自由軟體模式授權，試問，林正國可以針對 A 程式再跟其他公司談商業性授權嗎？

A6：(1) 可以。在未使用既有模組且係獨立開發的情況下，林正國是 A 程式的著作權人，他得以著作權人的身份，授權他人使用 A 程式（雙重授權），但為避免無謂的糾紛，林正國最好主動讓該公司了解 A 程式已採用自由軟體模式授權了。此種授權契約是私法性質的契約，因此林正國只要和被授權人達成合意，授權契約即成立。另外，林正國也可一開始就對 A 程式同時做自由軟體和商業性兩種不同的授權。

(2) 可以。不過商業性授權內容必須與 Y 授權條款相容。林正國開發 A 程式的過程中因使用了他人既有的 B 模組，故 A 程式授權方式的選擇，必須取得 B 模組原作者的同意。不過，在某些授權條款如 MIT，模組的原作者得允許改作人（在此例為林正國）就修改後的版本自由選擇其喜歡的授權方式，也算是已取得原作者的同意。（相容性的問題請見 Q2、Q3）

A7：一般人常會以為修正更新檔與原始著作具有某種的關連性（因為沒有原始著作就不會有修正更新檔），而誤認為修正更新檔是原始程式的衍生著作。然而，修正更新檔並不是衍生著作，原因有二：

(1) 修正更新檔實際上並不包含原始程式的內容。依我國著作權法的規定，衍生著作指：改作人將他人著作透過翻譯、編曲、改寫、拍攝影片或其他方法就原著作另為創作而產生之著作。因此，衍生著作必然會直接或間接包含原始著作的表達 (expression)。在電腦軟體的著作類型中，程式開發者如果想要直接修改他人之程式，或進一步散布修改後之程式，由於修改後程式會包含原始程式的部分內容，故修改後之程式將成為原始程式的衍生著作，改作人必須取得原著作權人改作權及散布權的授權，才能修改、散布他人之程式。

修正更新檔 (patch) 是一種引導使用者就特定程式加以修改的小程式，通常較原始程式檔案小得多，修正更新檔中的內容只包含刪除原始程式特定位址及新增程式碼的指令，並不包含原始程式的內容，故修正更新檔不具有著作權法上衍生著作必然會直接或間接包含原始著作表達的特性，所以不會被認定是原始程式的衍生著作，而是獨立的著作。修正更新檔的作者不需取得原始程式著作權人的授權，並可單獨為修正更新檔選擇授權條款。

(2) 原始程式著作權人不會因為他人散布其自行開發之修正更新檔，而受到經濟利益的損失。這是從修正更新檔對原始程式著作權人經濟利益的影響此一角度來觀察。著作權法規定散布衍生著作需經原始著作權人授權的理由，主要在於衍生著作的散布，多少都會影響到原始著作的銷售，為了避免造成原始著作權人的損失，故透過原始著作權人對衍生著作之散布具有同意權之機制，讓原始著作權人可向衍生著作權人收取權利金。修正更新檔因為實際上不包含原始程式的內容，且一定需搭配原始程式才有實質的功能，因此，使用者取得修正更新檔的同時，仍需要透過購買或是其他方式直接向原始程式著作權人取得利用原始程式的授權，原始程式著作權人不會因為他人散布其自行開發之修正更新檔受到經濟利益的損失，若仍授與原始著作權人對於散布修正更新檔之同意權，會造成過高的社會成本，也阻礙社會科技文化的創新。

Q8：承續 Q7，(1) 如果修正更新檔 (patch) 不是衍生著作，產生修正更新檔是否就不需要取得原始程式著作權人的同意？(2) 將修正更新檔安裝至原始程式上是否需要原作者之同意？

A8：(1) 不需要。承續 A7，修正更新檔是一獨立著作，而非衍生著作，故程式開發者開發修正更新檔，不需取得原始程式著作權人的同意。

(2) 需要。開發修正更新檔的作者雖不需取得原始程式著作權人的授權，但使用者將修正更新檔安裝至原始程式上的行為，即構成改作原始著作，故該使用者必須取得原始程式著作權人改作權的授權；然因常見的自由軟體授權條款皆有著作權人授與使用者修改其著作的權利的規定，在此種情況下，使用者可在原始程式所適用的授權條款的授權範圍內，安裝修正更新檔。

雖然程式開發者可為其開發的修正更新檔選擇獨立於原始程式的授權條款，但是考量到使用者安裝修正更新檔會構成對原始程式的改作，若修正更新檔採用與原始著作分別採用的授權條款不相容，將造成使用者無法合法安裝修正更新檔的窘境，因此開發修正更新檔的作者最好選擇與原始程式授權條款相容的授權條款釋出該修正更新檔。（相容性的問題請見「自由軟體授權方式之選擇」Q2、Q3）

Q9： A 程式是一個網路線上多人開發的自由軟體，目前最新的版本是 1.7 版，陳凱莉想在 A 程式 1.7 版上繼續開發後續的 1.8 版，陳凱莉除了需得到 A 程式 1.7 版作者的同意之外，還需要得到 A 程式更早版本作者的同意嗎？

A9：需要。電腦程式在開發過程中常會有不同版本程式的釋出，新版本程式除非完全捨棄舊有版本的程式碼另為開發，否則基於舊有版本加以修改而產生的新版本，不僅是前一版本的衍生著作，同時也是之前所有版本的衍生著作。

故陳凱莉想要修改 A 程式 1.7 版來開發 1.8 版，若 1.7 版的開發過程中參考了 1.6 版或更早之前的版本，則陳凱莉除需取得 A 程式 1.7 版開發者（團隊）的改作授權之外，同時也需取得之前所有版本開發者（團隊）的授權，才能對 1.7 版進行改作。

網路線上多人開發是目前自由軟體常見的開發模式，但這種模式卻易使著作權人與使用者間的法律關係過於複雜，必須仰賴自由軟體專案開發者在程式開發之初，事先妥善規劃完善的授權條款，才不會造成後續開發者的難題。

Q10： 林正國開發 A 程式的過程中，向張莊敬取得了一份他經常使用的 B 程式碼複本，而 B 程式的原作者則是陳凱莉，且 B 程式是以自由軟體模式授權。如果林正國想要以 B 程式作為開發 A 程式的基礎，需得到張莊敬的授權還是 B 程式原作者陳凱莉的授權？

A10： 須視授權條款之內容而定。以下就一般情形與少數特別情形分別說明。

一般情形，張莊敬雖是提供 B 程式副本給林正國的人，但張莊敬並非 B 程式的原始著作人，因此林正國必須取得 B 程式原作者（即陳凱莉）重製權或改作權等授權後，才能利用 B 程式。不過，由於 B 程式採用的是自由軟體授權模式，所以林正國只要遵守 B 程式所採用的授權條款規定，就可對 B 程式進行重製或改作等利用行為。

少數自由軟體授權條款，例如：MIT、MPL (Mozilla Public License) 及 CPL (Common Public License)，允許他人以自己（即授權人）名義將該軟體「再授權 (sublicense)」給第三人。如果陳凱莉採取的是類似前述三種授權條款釋出 B 程式，則張莊敬在符合該授權條款的約定下，得以張莊敬自己為授權人，在陳凱莉授權給張莊敬的範圍內再授權給林正國，此時，授權契約的當事人便是張莊敬與林正國。在這種「再授權」的情況，對於被授權的林正國來說，一樣可以取得有效的重製或改作的授權，差別僅在於授權人是被授權可為「再授權」的張莊敬，而非 B 程式原作者陳凱莉。

【按】：一般來說，會特別需要採行「再授權」的情形，較常發生在某一手程式開發／利用者（通常是商業公司）針對某程式加以商業化販售，而該程式之購買者要求和該公司直接訂立授權契約之情況。不過，允許第三人可為再授權的自由軟體授權條款並不多，因此，被授權人在與此等商業公司簽訂授權契約時，必須特別注意該程式原本之授權條款中是否有允許此等商業公司「再授權」之約定。若有，該公司在遵守原授權條款「再授權」的規定下，便能以該公司自己為授權人和購買者訂約；若無，縱使購買者和商業公司簽訂了授權契約，仍欠缺原程式著作權人的「再授權」，該購買者將無法合法地利用此程式。

問題 1  關於軟體專利的授權，請問 GPL 有無規範？

GPL-2.0 究竟有無明定「軟體專利授權」存在著爭議，有人認為有，有人認為沒有。認為 GPL-2.0 已明訂軟體專利授權條款的人，主要根據來自第7條：任一 GPL-2.0 授權的程式一經散布之後，就必須完全依照 GPL-2.0 的規則來提供修改、應用、重製與散布，即使上面有經司法訴訟判定的軟體專利權利，亦同，若不能做到這點，散布者就不得散布這個 GPL-2.0 授權的程式。

然而，部分論者認為GPL-2.0 第7條僅在表達一種態度，而未明文處理軟體專利授權議題，因為第7條確實從頭到尾並無明示「依據 GPL-2.0 取得程式著作權授權之人，一併取得其軟體專利的使用授權。」那麼，依照各國著作權法，著作財產權授權約定不明的部分，多推定為未授權；而專利權的授權方面，慣性上也多以明示的書面授權文件為準，所以推論上，並沒有強而有力的具體根據，認為僅依 GPL-2.0 第 7 條的規定，就認定該條款規範了明確的專利授權機制。GPL 改版至 3.0時，處理了這個議題，其明文規範依據 GPL-3.0 取得程式著作權授權之人，一併取得其軟體專利的使用授權。自此之後，採 GPL-3.0 授權的元件，軟體專利有無隨同授權的爭議已不復存在，然GPL-2.0關於此議題，還存有懸而難解的灰色地帶。

關於 GPL-2.0 第 7 條的推論與說法的進一步說明，可以參照葛冬梅小姐與林誠夏先生合寫的「GPL-2.0 第 7 條淺評」的短篇專文 

問題 2  （承上）GPL 若有關於軟體專利授權的規範，有無區分「衍生程式的專利」和「獨立程式的專利」？

所謂獨立程式，依照一般通說，指的是其並非參考GPL程式來撰寫，該程式也可以被其他程式呼叫，或呼叫其他程式；而其與 GPL 程式的結合，只是置於同一個專案裡去進行功能上分工，這種狀態的話，該程式的授權狀態未必直接受到  GPL 程式的影響。

因此，一般來說，個別元件被判定為「獨立程式」的話，不論是 GPL-2.0 或 GPL-3.0 的所有授權規則都不會過渡到其上。所以依照這樣的論述，在一個大型軟體專案裡，「GPL 元件衍生程式的專利」與「GPL 元件獨立程式的專利」是有分立與分別主張的機會的。

問題 3   我所開發的 A 元件依 Apache-2.0 貢獻出來，且 A 元件上內嵌有我所擁有的專利，請問依照 Apache-2.0 規定，別人對A元件如何的使用不在我專利授權的範圍內？

您依 Apache-2.0 貢獻出來的 A 元件，只要其他元件的程式碼與其有連結呼叫 (link) 或是程式碼交融 (merge) 這樣的結合關係 (combination)，那這個專利授權是及於這些組合後的專案或是產品的；改寫 A 元件（即產生 A 元件的衍生元件）之後的組合狀態亦同，因為此時A元件本來的程式碼也還在衍生元件裡，只是處於一個被修改過後的衍生狀態；然而，若是新的專案、新的產品中完全沒有 A 元件程式碼的存在，則本來依附於 A 元件的軟體專利，是不會一併擴及到這個專利與產品上的，換句話說，此時這個新專案、新產品是不能合法利用您原本內嵌在 A 元件程式碼之上的軟體專利的。

問題 4  （承上）伴隨 A 元件一併散布出去的軟體專利權利，是否只包含我將所開發的 A 元件依 Apache-2.0 貢獻出來當時已申請到的專利？

會隨著 A 元件一併散布出去的軟體專利權利，包括已申請到的，和未來可以申請的，因為 Apache-2.0 使用的並非「軟體專利 (patent right)」或是單一的「專利 (patent)」這樣的既定名詞，而是特別選用「專利技術保護範圍 (patent claim)」這個涵攝更廣的概念。

其實強調此一名詞的效果就是，不管這個專利被核可過了與否，只要是程式的撰寫者自主的將這樣的技術方法寫入 Apache-2.0 授權的A元件裡，那麼 A 元件後續的使用者，就可以依照 Apache-2.0 的規則來使用這些技術方法，而不會被告專利侵權。相同的概念在 GPL-3.0 的條款裡也有被表述出來，例如其第 11 條第 2 項就明白指出，所授權出去的技術方法包括所有授權者能掌握的必要專利範圍，包括程式釋出時已經取得的專利技術，或是嗣後方取得的專利技術。 (A contributor's “essential patent claims” are all patent claims owned or controlled by the contributor, whether already acquired or hereafter acquired...)
 

問題 5  如果我程式撰寫過程中使用了某個自由開源軟體，之後若有人對這個自由開源軟體提起專利權侵害訴訟，那麼我是否就需停止使用該軟體？

若是您所撰寫的程式，僅提供個人使用或學術研究等不涉及商業利用的目的，原則上並不會有專利侵權的問題，因為這是在專利合理使用的範圍之內。但如果您所撰寫的程式未來會進行商業利用，而程式中所採用的自由開源軟體可能有專利侵權疑慮，那麼若日後真的發生專利侵權情事，您就必須將專利侵權部份從您所 撰寫的程式中拿掉。

問題 1  請問代客安裝自由開源軟體、並收取服務費的行為是否合法？

是合法的，但有以下幾點需注意。

1. 所有自由開源軟體授權的軟體元件，都可以拿來進行商業利用，但商業利用時，也必須遵守個別授權條款的相關規定。
2. 自由開源軟體授權原則上是以不收取著作權權利金、專利權權利金的方式進行散布，這是因為授權金的收取方式，向來有「授權對象、授權地域、授權期間」的限制，這些限制與自由開源軟體允許使用者自行修改、自行重製散布的模式有衝突；然而，只要收費模式與自由開源軟體授權條款的規則不相衝突，那都是可以收取的。
3. 然而商標權的授權金在自由開源軟體領域是可以收取的，這是因為商標權是以圖標、圖形的方式(mark, logo)來顯現，這些圖標、圖形是可以被使用者自行移除掉的，只要自行移除掉，那就不會有商標授權方面的問題。

所以商業使用自由開源軟體，要附帶注意到商標授權的問題，如果不欲支付商標授權金的話，需注意 (1) 不拿商標本身與此商標有關的字樣來為商業服務廣告宣傳，僅能事實性的標註該專案的利用狀態；(2) 實際產品在散布時，手動移除掉涉及商標授權的圖標與圖形。如果不能達致上述 (1)、(2) 兩個方法，並且涉及商業利用的話，那麼使用者最好另行洽談取得該商標的書面授權。

進一步資訊您可以參考下列文章：淺談使用自由軟體時所應注意的商標授權問題。

問題 2  何謂「商業利用」？ 如何判斷一項軟體的使用行為是否屬於商業利用？

針對「商業使用」的具體界定範圍，各國法律在傳統商業領域或有相關的成文法律規定，例如公司法、證券法等……，但對於網際網路的新興領域，則存有較大的模糊狀態與解釋空間。因此在新興領域裡，不同的解讀者，會有不同的解釋角度，也就是說，個別的網站服務或是軟體專案，可能有其對於商業利用行為的詳細規定與說明，例如 Google Maps API 的服務條款，就是透過契約內容補充的方式來釐清範圍。不過，若是網站的架設者與軟體的散布者就此並未有預先的說明，則就一般法律原則來說，就是考量「服務與軟體的取得與金錢付出是否有對價關係」，若是有金錢對價關係者，則很容易被定位為商業利用行為，反之，則有可能逸脫於商業利用行為的範圍。例如行動式 App 應用軟體置於軟體市集讓人免費下載，但連帶嵌入廣告，此種運作模式，若是軟體下載時契約明定「使用者不得將廣告機制關閉」，則此種運用模式便近似於對價式的商業利用模式，因「內嵌廣告」可以轉換為金錢收益，與「程式提供使用」之間已經產生「直接交換關 係」。但由於實際運用模式可能會有不同的變數，因此，除了將軟體置於收費線上平台或實體商品出售等等，這類很明確的情況之外，一個軟體的利用方式是否屬於商業利用，必須要以個案來判斷。