受保護的內容: COSCUP 2024 演講：GPL 授權條款的典型侵權糾紛
受密碼保護的文章不會產生內容摘要。
標籤: GPL
舊文重新上架 << 從 Copyright 到 Copyleft：GPL 的誕生、成長與未來 >>
有社群朋友在 2022 年 6 月跟我詢問這篇文章何處可以下載,由於鑄造場
網站上的下載連結已經失效,因此我找出塵封的文章,更新了聯絡的 email 與
日期後,將此文章放在我的網誌上供有興趣的人下載。
若沒記錯，這篇文章是應該是是 2005 年完成的，當年剛開始在自由軟體鑄造場工作，一群人豪情壯志地想要出一系列自由開源軟體相關的書籍，不過最終只有規劃中的第二本完成了內容。
第二本是以法律的角度來談自由軟體，透過不同作者、不同主題、不同角度，來帶領讀者了解自由開源軟體在法律面所呈現出來的態樣。原書預定的第三篇就是我的這篇文章，目的在於透過盡可能的白話文字來讓一般人也可以概要了解 GPL 第二版授權條款 (GNU General Publice License Version 2.0, GPL-2.0) 的內容。
但是礙於諸多因素，這本書最終沒能付梓印刷成實體紙本，所以到了 2006 年中，我們將書的內容放到了鑄造場的網站上，經所有作者同意採用「創用CC 姓名標示－非商業性－禁止改作 授權條款 台灣 2.0 版」來散布，希望可以讓有需要的人閱讀到這些內容。不過後來鑄造場計畫結束，OpenFoundry 網站在一段時間之後也無法正常維護，所以這本書文章的下載連結內容均已遺失，無法真實下載到文章內容，只能瀏覽書的單篇文章標題：
https://www.openfoundry.org/tw/events-and-conferences/cat_view/214-/209-/231-2005-ossf-books
近來有社群朋友向我詢問這篇文章，所以我將當媽之後幾乎塵封的硬碟翻了出來，尋著當年的資料夾架構邏輯，找到了許多不甚合乎邏輯的相關檔案名稱，最終確認翻出了這篇文章。十分感謝 Lucien C.H. Lin 定期幫我更換儲存硬碟，所以文章內容至今完好無缺。
這篇文章撰寫完成於十多年前，雖然在這段時間的相關用詞、觀念、實務發展與現實環境都有很大的轉變，但是由於沒有時間琢磨內文修改刪增，因此內文還是跟當年一樣，只有加上一些額外的說明文字與更新資訊，特此說明。
最後歪樓的感謝一下這位詢問文章的社群朋友，讓我在這麼多年後再度更新了一篇網誌！
受雇人利用 GPL 元件開發公司產品的著作權歸屬與運用疑義解析
這篇文章原本刊登於自由軟體鑄造場的法律專欄，感謝Lucien對本篇文章所提供的意見。
~~~~~~~~~~ 本文開始 ~~~~~~~~~~
所謂的受雇人，簡單來說，就是在一間公司或組織聘用來在負責一定職務工作的員工，因此受雇於一間公司來專職開發軟體、韌體的工程師，就是受雇人，而該公司就是雇用人（註一）。若是這間公司利用 GPL 元件來開發產品，軟體工程師可以自由散布產品程式碼嗎？工程師在產品中所撰寫開發的程式碼，其權利是屬於工程師本身、還是該公司？這些疑問是受雇軟體工程師在利用自由開源軟體來開發產品時，可能會產生的，因此本文將先從著作權法相關的規定談起，並且說明實際雇傭關係的運用狀況，進而釐清這些可能的疑問。 閱讀全文〈受雇人利用 GPL 元件開發公司產品的著作權歸屬與運用疑義解析〉
釋出源碼時常見的考慮因素與授權條款的選擇：以單一著作權人的軟體專案為例
最近接觸到一個想要釋出源碼的專案，該專案程式碼的著作權利全部歸屬於單一著作權人，因此這個專案可以選擇的自由開源授權條款很多，能變化出來的授權模式(licensing model)也十分多樣，不過由於著作權人的目的相當單純，主要就是希望釋出源碼。不過一個軟體專案釋出源碼還會產生附帶的效應，這些效應會隨著授權條款的改變有所不同，為此我簡單整理了一下採用自由開源模式授權出來的專案可能會產生哪些重要的效果，以及有哪些條款可以產生這些效果，內容不見得完整，但是可以用來初步了解一些常見的考慮因素與授權條款之間的關係。。
當然，每一個軟體專案的狀況不一樣，要考慮的因素也不盡相同，因此以下內容對於軟體專案著作權人單一或單純的情況較為適用，例如：著作權人僅有二人，而這二位著作權人剛好為好友，對於軟體專案未來的規劃想法一致，很容易取得共識。若是專案著作權人為不易產生共識的多數，又或者專案利用到GPL授權的第三方程式碼時等狀況，這時候本文內容的參考價值就沒那麼高。不過若是一個軟體專案還處在初期開發階段，是否採用第三方程式碼尚未確定，專案將如何被散布利用也還在規劃當中，本文的內容則可以在討論、選擇授權條款／模式時，一個蠻好的參考資料。
由於專利是另外一個專門的議題，因此這篇文章也沒有將專利授權納入考量因素之內。
最後，由於篇幅有限，因此以下內容並沒有針對個別授權條款的內容與特性多加說明與闡釋，對於個別授權條款的內容與性特請參見所附連結的文章。
1. 希望軟體專案具有快速的擴散性與高度的發展性
可以採用BSD、MIT、Apache-2.0這些單一條款來授權。
這些條款的特色在於使用者義務很少，僅有在散布的時候必須保留著作權聲明與免責聲明，但是並沒有義務一定要將程式源碼提供給予取得程式的後手。由於義務規定如此少，因此這些條款授權的軟體很適合用來開發閉源的商業產品。Windows作業系統中有應用許多自由開源軟體 (FOSS)，這些FOSS大多都是BSD、MIT或Apache-2.0等條款授權的。不過相對地，這樣的授權特性雖然有利於專案的散布，但也同時便利其他開發者修改後發展出其他的應用或功能。
BSD介紹：
http://www.openfoundry.org/tw/legal-column-list/524–bsd
MIT介紹：
http://www.openfoundry.org/tw/legal-column-list/513–mit
Apache-2.0介紹：
http://www.openfoundry.org/legal-column-list/8581-the-elaborate-license-apache-20?lang=tw
GPL 與常見授權條款相容性淺析
本文原刊登於自由軟體鑄造場的法律專欄。
~~~~~~~~~~ 本文開始 ~~~~~~~~~~
GPL 是被廣泛採用的自由開源授權條款，不過由於 GPL 具有授權拘束性，衍生程式必須仍然適用相同條款授權（註一），所以在利用上會需要注意與之結合的程式碼授權內容是否相容，因為與之結合的程式碼一旦成為 GPL 衍生程式，就代表著在散布時必須要透過 GPL 條款來授權散布，若是其原本的授權內容與 GPL 不相容，會讓使用者無法同時符合兩份條款的義務規定，進而可能發生侵權利用的狀況。
因此本文將以 GPL-2.0 與 GPL-3.0 這兩份授權條款為中心，來說明目前常見授權條款是否與之相容，進而讓讀者了解哪些常見授權條款的程式碼可以與這兩份 GPL 條款的程式碼結合之後一起散布（註二）。
▲ 圖1：GPL 衍生程式結構示意圖。
自由開源軟體侵權爭端案例文章彙整
近來在整理法律專欄中，跟自由開源軟體侵權相關的文章，也同時將鑄造場網站上相關的新聞報導也做了整理。在鑄造場工作了這麼多年，雖然沒有一案不漏地介紹過所有侵權爭端案例，不過重要的案件都沒有漏掉。只是其中有些文章沒有做後續更新，因此資料仍是舊的，是比較可惜的地方。
【新聞報導】
一、BusyBox 侵權案件（違反GPL）
「Monsoon Multimedia 與 BusyBox 的 GPL 侵害訴訟達成和解」
http://www.openfoundry.org/tw/foss-news/1287
「SFLC 控告 Verizon 違反 GPL 散佈開放源碼軟體」
http://www.openfoundry.org/tw/foss-news/1334
「BusyBox 開發者與 Xterasys 取得 GPL 侵權訴訟和解」
http://www.openfoundry.org/tw/foss-news/1353 閱讀全文〈自由開源軟體侵權爭端案例文章彙整〉
利用自由開源軟體元件開發雲端應用專案
本文原刊登於自由軟體鑄造場的法律專欄。
~~~~~~~~~~ 本文開始 ~~~~~~~~~~
雖著網際網路的進一步發展，近年來雲端運算成為一鼓新興的潮流，無論是大型的商業公司或小型的資訊服務業者，乃至於個人工作室，都乘著這鼓潮流，嘗試開發網路應用程式或提供相關的商業服務。與一般的軟體開發專案一樣，在開發網路應用程式或線上服務平台（以下統稱這些應用程式與服務平台的開發專案為「雲端應用專案」）的時候，也可能面對部份專案內容無法對外提供程式源碼 (Source Code) 的情況，例如雲端應用專案中某一部份的程式碼，因為受到第三方保密協議的拘束，所以不能對外提供源碼與相關資訊。這樣的專案若仍想要利用自由開源軟體元件來開發的話，那麼選擇哪些條款授權的元件，才不會造成未來應用時產生必須提供程式源碼的衝突，將是開發過程的一項重點。因此，本文將針對常見的自由開源授權條款（註一），說明相關的義務規定，據此建議雲端應用專案可以選擇哪些條款授權的元件，以避免無法提供源碼的專案產生授權義務上的衝突。
從產品租賃來看 GPL 的散布定義與範圍
此篇文章原載於自由軟體鑄造場網站上的「法律專欄」，與林誠夏共同撰寫完成。
~~~~~~~~~~ 本文開始 ~~~~~~~~~~
GPL 授權條款有著許多不同於傳統軟體授權方式的相關規定，其中散布程式的時候必須提供源碼的規定，則是影響最大、也最常被違反的一項。這項義務與其他 GPL 條款中所規定的義務一樣，都是透過散布行為而被開啟，也就是說，程式被利用或移轉的方式若不是 GPL 條款所定義的散布行為，散布者就可以自由選擇是否要去遵守其他後續的相關義務規定。因此散布的內涵有著左右 GPL 義務規定是否被啟動的重要地位。
在單純的例子裡，大家都可以輕易理解什麼是散布，例如甲從網路下載了 GPL 程式 A 之後，再將程式 A 拷貝到朋友乙的電腦中，這時候程式 A 就是從甲的手中被散布到了乙的手中，因此依照 GPL 規定，甲負有將程式 A 源碼提供給乙的義務。但是隨著資訊科技的發展與商業交易行為的多樣化，使用者可能在利用銀行自動化設備與租借嵌入式裝置的同時，而間接利用到、或者甚至間接占有了 GPL 程式一段期間，例如前一陣子才停止網路電視服務的壹多傳媒，該服務出租網樂通機上盒給予客戶，客戶只要自行將顯示螢幕與網路線接到機上盒，就可以收看所提供的網路電視節目，這個機上盒為嵌入式的 Linux 作業系統，有利用到很多 GPL 程式，但是壹多媒體在最初時並沒有釋出機上盒的程式源碼，因而引發後續爭議，就是一個典型的例子。這種透過出租產品與提供服務，所造成程式碼移轉的行為，是否也屬於 GPL 所規定的散布程式碼的行為？針對這個問題，本文將會針對目前被廣泛採用的 GPL-2.0 與 GPL-3.0 說明相關規定，並嘗試釐清問題的癥結點，期望可以拋磚引玉的讓大家對這個議題，有一些基本的認識。
如何提供 GPL 元件的程式源碼
GPL 授權條款制定的目的，是希望人人都可以研究、修改與散布程式，為了要達到這個目的，取得程式源碼 (Source Code) 是不可或缺的前提要件。因為雖然一位有能力的開發者在拿到目的碼的狀況下，也有可能透過逆向工程來將程式還原到源碼的形式，但這畢竟非常不便，也不是常態，很多情形下也有違法侵權之虞。因此在 GPL 授權條款的規定中，提供程式源碼是一項非常重要的義務，針對程式的研究與修改，透過源碼形式來進行是最為便捷的。而為了讓任何一位拿到程式的後手使用者，都可以順利取得相對應的程式源碼，GPL 設有一套規定散布者如何提供程式源碼的規定，來保障這些源碼可以持續地被後手取得。
此篇文章原載於自由軟體鑄造場網站上的「法律專欄」。感謝林誠夏對於本文所給予的修正。
~~~~~~~~~~ 本文開始 ~~~~~~~~~~
GPL 授權條款制定的目的，是希望人人都可以研究、修改與散布程式，為了要達到這個目的，取得程式源碼 (Source Code) 是不可或缺的前提要件。因為雖然一位有能力的開發者在拿到目的碼的狀況下，也有可能透過逆向工程來將程式還原到源碼的形式，但這畢竟非常不便，也不是常態，很多情形下也有違法侵權之虞。因此在 GPL 授權條款的規定中，提供程式源碼是一項非常重要的義務，針對程式的研究與修改，透過源碼形式來進行是最為便捷的。而為了讓任何一位拿到程式的後手使用者，都可以順利取得相對應的程式源碼，GPL 設有一套規定散布者如何提供程式源碼的規定，來保障這些源碼可以持續地被後手取得。
淺談商業公司額外附加的「例外許可條款」
此篇文章原載於自由軟體鑄造場網站上的「法律專欄」。感謝林誠夏對於本文所給予的撰寫建議。
~~~~~~~~~~ 本文開始 ~~~~~~~~~~
商業公司將自由開源軟體做為營利產品或是服務內容已經不是新聞，而隨著商業化程度的加深，這些商業化應用的自由開源軟體也開始在授權條款方面出現變化，其中最常見的變化是在既有的開源模式之外，加上不同的授權選擇，雙重授權模式（註一）就是一個典型而著名的例子，這種模式讓使用者可以在自由開源授權與商業授權之間做選擇，以符合其不同的需求，同時也維持了商用自由開源軟體的多重目的。不過除了雙重授權模式之外，還有一種因應嚴格授權拘束性（License Inheritance，註二）而附加的「例外許可條款」（以下簡稱「例外條款」），讓使用者在應用 GPL 類元件產生衍生程式之後，有著為衍生程式選擇非 GPL 類授權方式的可能性，同時也維持商用自由開源軟體的多重目的。