本文原本刊登在自由軟體鑄造場的法律專欄，主筆是Lucien，以Lucien之前為”IFOSS Law Book“第二版所撰寫的「台灣專章」為基礎來延伸撰文，我負責閱讀與提供德文資料、共同討論與潤飾文字，因此Lucien為本文的第一作者。
這篇文章以大型的自由開源軟體專案(Free and Open Source Software Project, FOSS Project)為客體，討論FOSS Project應該屬於我國著作權法上的的哪一種著作型態：共同著作？衍生著作？抑或者是編輯著作？FOSS Project對應到這些不同的著作型態會產生結構不同的著作權人組成與著作權保護期間，但是這樣的問題並沒有被充份討論過，因此這篇文章嘗試進行這樣的邏輯分析。
文中提到德國著作權法第9條結合著作(Compound Work/Collective Work)，是一個台灣著作權法所沒有的著作型態，但是我覺得相當適合套用在大型、融合許多第3元件的FOSS Project上，若是要為自由開源軟體在台灣著作權法上爭取一個明確身份的話，德國著作權法這樣的規定相當值得參考。
~~~~~~~~~~ 本文開始 ~~~~~~~~~~
林誠夏、葛冬梅／文
自由開源軟體專案 (Free and Open Source Software Project, FOSS Project)，其在著作權法上的保護地位，與一般電腦程式無異，因電腦程式受法律保護所必須具有的創意性與科學性，在 FOSS Project 上一項也不缺少，然而，FOSS Project 的撰寫與創作過程，卻迥異於一般傳統的私有軟體 (proprietary software)，以至國際間許多與自由開源軟體相關的司法訴訟，其在進行初始法律關係的分析時，亦不乏從其著作權類型如何歸屬討論起，例如 2011 年德國柏林地方法院 AVM vs Cybits 一案的判決，便曾在言詞辯論時，就嵌入式韌體裝置上各元件應歸類於哪一種著作類型而展開討論（註一）。
那麼就國內現行的著作權法規範，應如何給予自由開源軟體定性，以最適切的方式來解決 FOSS Project 實務上可能涉及的繁複著作權利分配問題，而若現行法律有所不足處，未來在增修上應如何調整，便為本文主要的探討主題。
▲ 圖1：德國柏林地方法院 AVM vs Cybits 一案之二審確定判決書
【電腦程式在國內法律的保護適格】
電腦程式在台灣的保護，主要是以著作權法 (Copyright Act) 為其基礎法律 (general law)，其並沒有獨立設立軟體保護的特別法 (special law) 來規範，而是在著作權法中設置予電腦程式適用的專門條款來進行規範。而一般來說，在台灣電腦程式要受到著作權法保護的門檻並不高（註二），主要是：
- 必須能夠證明該電腦程式的寫作過程，並非是機械化、純數理過程的推展與呈現；其次是，
- 此一電腦程式的創作過程仍具有創作人智慧的投入，則已足。
故絕大多數的電腦程式創作，都是受到著作權保護的，並且依照著作權法第 10 條預設的「創作保護主義」：「著作人於著作完成時享有著作權。」一個電腦程式只要是著作人的智慧結晶，便自動可以取得著作權法下的保護適格，著作人毋須透過任何額外程序的登記，或是申請來取得著作權利，且無論這個電腦程式是以自由開源軟體的授權方式，亦或是採私有軟體的授權方式進行後續的應用。
【當前著作權法無法完全適切對自由開源軟體授權程式進行型態分類】
然而，FOSS Project 對於當前著作權法的挑戰在於，其之編撰方式與流程，為一個多人共工、聚沙成塔，且不斷吸納參與者智慧貢獻的著作權客體，這和當前既定著作權法對於電腦程式創作所想像的預設過程有著相當大的落差。一般來說，現行台灣著作權法第 8 條的共同著作 (joint work) 與第 6 條的衍生著作 (derivative work)，是二個最有可能被拿來比附援引、了解 FOSS Project 權利分配狀況的著作型態，然而這二個著作權法預設的著作類型，與自由開源軟體的實際開發狀態，在對比上亦各有各自的欠缺與不同。此外，著作權法第 7 條的編輯著作 (compilation work) 規定，著作經選編之後，視為獨立的著作權利客體，因此編輯著作也可能是另外一個用來比附援引 FOSS Project 的著作型態。然此編輯著作的編輯過程須有選編上的創意性，並且權利保護期間另行起算；但程式元件彼此間常見的集合型態 (aggregation)，有時選編上並未具創意性，而僅是功能上的結合，若僅因為純粹功能性的搭配，就讓結合後的專案取得編輯著作獨立的保護地位，並另行起算完整的權利保護期間，恐怕更不是一個合乎法律論理的分類方式。
【將自由開源軟體以共同著作的方式解讀】
依著作權法第 8 條規定：「二人以上共同完成之著作，其各人之創作，不能分離利用者，為共同著作。」所以原生的 FOSS Project，創作人彼此間若具有充份共同創作意思的聯繫與互動，則該專案便會被認定為共同著作，而能夠適用共同著作在著作權法裡，預先設定的各項機制。然而該 FOSS Project 如繼續被其他參與者進行修改，其後的著作權利如何進行分配，就是一個饒富趣味且值得討論的問題。因為其後此一 FOSS Project 的接力參與者，可能僅依循授權規則與開發風格 (coding style)，便以程式碼撰寫接力的方式來繼續進行電腦程式的協作，這是一種「未必經過溝通協調的合作模式 (cooperation without coordination)」，此點與現行著作權法對於共同著作的定義，似乎並不能說是完全相合。因傳統上對於共同著作的解釋，旬認為共同著作人之間，對於共同著作應具有共同創作意思之溝通與聯繫，此一認知和多數 FOSS Project 的運作狀態，便有了相當的落差。
【將自由開源軟體以衍生著作的方式解讀】
FOSS Project 經過一定程度的增補與改作之後，將有機會形成著作權法第 6 條所定義之衍生著作，並依法得以獨立著作之地位保護之。因為依著作權法第 28 條規定，著作的改作權專有於原著作的著作財產權人，然而只要是 FOSS Project，其皆透過授權條款的預先聲明，將原專案的改作權授權予後續專案的改作者，所以在自由開源軟體的開發歷程裡，後續專案被認定為前手專案的衍生著作，此一模式可說高度符合著作權法在衍生關係上建立的法律架構。然而傳統上對於衍生著作的解釋，亦要求衍生程式與原生程式之間必須要有相當創意性的改作，方才能夠成為一個具獨立著作權保護地位的衍生著作，此一標準和多數自由開源軟體專案的持續開發歷程或有相當落差，因為在相當期間裡，許多 FOSS Project 的參與者，是就原生程式漏洞進行修補與小功能的改寫，這些微量的程式碼貢獻單筆單筆區分來看，其創意性皆不足以獨自成為著作權保護的客體，但經歷一段時間與數量的累積後，卻可能統合為一個更新版本的電腦程式專案，這是一種透過眾人持續貢獻累積程式碼所造成的改作模式，此點與現行著作權法對於衍生著作的定義亦不完全相同。
【試將共同著作與衍生著作型態依自由開源軟體的開發實務套用之】
從上所述，可以發現，要單純以個別共同著作或是衍生著作的分類與型態，套用到 FOSS Project 的開發上，都各自有所欠缺。然而，若是依著 FOSS Project 的開發實務，以分時序與參與序的階段化方式，再配合成熟的 FOSS Project 皆會定期改版釋出的特性來解釋，則共同著作與衍生著作的型態，便可以合法合份的套用到 FOSS Project 這種特殊型態的軟體著作上：
- 原生的 FOSS Project，創作人彼此間若具有充份共同創作意思的聯繫與互動，則該專案便可先被認定為共同著作；而或者雖然創作人彼此之間，可能沒有直接聯繫討論的關係，但卻可以援引自由開源軟體授權條款的預先公示性，解釋此些條款的預先揭示與認同，即已充足「共同創作意思聯繫與互動」之條件，因創作人在加入 FOSS Project 的開發之際，必然已經對授權條款的預訂內容有所認定，再者，個別專案亦有相應的參考文件，可讓其依循其他共同創作者認同之開發風格與除錯回報流程，故此時便可擴大解釋，將此 FOSS Project 初始版本的 version 1.0 認定為所有共工編寫者之共同著作。
- 其後此一 FOSS Project 接續被後續參與者提報 bug 與除錯，並不斷的被加寫新的功能與元件，在創作過程中，如果僅是針對原生程式漏洞進行修補與小功能的改寫，這些微量的程式碼貢獻單筆單筆區分來看，皆毋須獨自認定為受著作權保護的獨立客體，因此時創意性與完整性並不成熟，然而，在經歷一段時間與數量的累積後，該 FOSS Project 正式釋出更新版本的 version 2.0 時，再將 version 2.0 視為著作權法第 6 條所定義之衍生著作，而原先第一版本 version A 中的程式碼，若有未經改寫予以保留的部份，則在 version A 裡這些程式碼的創作人，則與 version B 開發歷程中的參與者與投注者，一起列名為 version B 這個衍生程式的共同著作人；而若是 version A 版本的創作人，亦一起參與 version B 之實作時亦同。也就是說，該 FOSS Project，於 version B 的釋出階段時，相對於 version A 是既衍生又共同的著作型態。
【在編輯著作之外另行設立結合著作的類型以充實自由開源軟體的組成態樣】
以上的運作模式，已幾乎可以善加處理 FOSS Project，在當前實務上涉及的繁複著作權利分配問題。然而，有時候 FOSS Project 的後續更新版本，僅是原封不動取用前一版本中部份的元件，例如函式庫 (library) 性質的電腦程式，並讓專案裡的其他元件，透過公開的應用程式介面 (application program interface, API) 來和這些函式庫互動，此一對原元件／函式庫的取用行為，能不能構成著作權法上的改作行為，則是迭有許多不同的法律見解，有些論者將這樣的利用狀態定義為德國著作權法第 9 條的結合著作 (Compound Work)，或可能是美國著作權法第 101 條項下的編輯著作（Collective Work，註三）。但基於目前國內的著作權法，並沒有如同德國著作權法有明定 Compound Work 的型態，也沒有美國著作權法 Collective Work 的設計，故此種狀況在台灣司法實務上，最有可能的認定方式，便是將其認定為著作權法第 7 條編輯著作的型態，而後再依編輯著作的相關規定進行利用。然而，進一步探究現行編輯著作的立法原則，是要求素材在選編過程之中必須具有創意性，才能在選編之後視為獨立的著作權客體來進行保護，而實務上，多數 FOSS Project 項下的各獨立元件，僅是具有功能性取向的結合，例如許多自由開源性質的「內容管理軟體系統 (Content Management System, CMS)」，其在資料庫系統的配合與使用上，可使用 GPL-2.0 授權的 MySQL 資料庫，亦可使用其衍生的分支版本 MariaDB，除此之外，還有 BSD-like 授權的 PostgreSQL 資料庫，以及被權利人拋棄權利到公眾領域 (Public Domain) 的 SQLite 資料庫可以使用，這些 CMS 與資料庫軟體之間的結合運作，常常是不具有選擇上的創意性，單純僅就功能、運作效益與硬體資源限制的考量，若將此種結合型態視為一般的編輯著作，便讓結合後專案的權利保護期間另行起算，並取得著作權法上獨立的保護地位，恐怕亦非合乎法理邏輯的處置方式。
故建議是可以參酌德國著作權法第 9 條的規定（註四），將 FOSS Project 專案裡獨立運作元件彼此間的結合關係，視為一不同於編輯著作型態的結合著作 (Compound Work)。此時此結合著作並不會獨立取得一個著作權的保護地位，而是被視為不同的著作客體因共同利用的目的，而進行功能性或互補性地位的結合。原則上結合著作裡的個別著作人，要對結合著作進行公開發表、經濟利用，以及內容的修改時，仍然需要得到其他結合著作權利人的同意方可為之，但其他結合著作權利人沒有正當理由者，亦不得拒絕之。可以說，德國著作權法此一結合著作的型態，核心要處理的是這些因功能性結合的著作，其個別著作權利人的內部關係，而不是另行創生另一個統合的著作權客體，所以從 FOSS Project 的實際編撰模式與社群運作典範來看，確實此種著作類型，會更符合自由開源軟體的開發模式，亦不會與現行著作權法的其他機制產生嚴重的衝突。
大體來說，就國內著作權法目前的現行規定，依 FOSS Project 在開發期程上的歷程與階段，可將其類推為共同著作或原生專案的衍生著作來看，在法律架構上並不會產生本質上的衝突。原則上，多人同時同期分工創作且不可分別利用者，其成品可被歸類為共同著作，而若多人前後不同時期接力創作，其後的改作作品經不同版本的釋出後，可被歸類為衍生著作。故實務應用上，應先查驗特定 FOSS Project 在運作上的狀態，若是該專案的參與成員彼此在撰寫分工上具有高度合意與互動，則可依民法第 1 條類推適用的法理，優先讓其比附援引共同著作的相關規定，而若該專案為其他 FOSS Project 的後續版本，則可優先讓其類推適用於衍生著作的相關規定。然而，現行台灣著作權法對著作物型態的預設分類，並不能完全契合自由開源軟體的運作特性，主要就是在結合著作的類型上有所欠缺，所以實務上還必須輔以授權條款個別內容的解釋，與著作權法相關條款的類推適用 (mutatis mutandis)，才能運作順暢，而日後著作權法在修改上，亦可參酌德國著作權法關於結合著作的運作型態，來充實此一缺漏，並補充現行法律在著作型態界定上的不足（註五）。
註一：就本案進行訴訟參與的歐洲自由軟體基金會成員，德國執業律師 Till Jaeger 博士於言詞辯論指出，嵌入式韌體裝置中與 GPL 授權元件相融合在一起的程式元件，應為 GPL 授權元件之衍生著作，而其他可分割出來獨立運作的元件，則與 GPL 授權的衍生著作合併為德國著作權法第 9 條之結合著作 (Compound Work)。此判決進一步的相關資訊，可見歐洲自由軟體基金會整理的案件報導：http://fsfe.org/activities/ftf/avm-gpl-violation.en.html，以及確定的第二審德文判決書：http://fsfe.org/activities/ftf/lg-urteil-20111118.pdf。
註二：依據現行著作權法第 5 條第 1 項第 10 款，以及第 3 條，第 10-1 條，關於著作定義與例示分類之規定。
註三：美國著作權法就 Collective Work 之外，亦同時對 Compilation Work 進行定義，其規範 Compilation 為 Collective Work 的上位概念，故某著作被分類為 Collective Work 時，其在美國法的認定上也必定為一 Compilation。部份譯者是將 Collective Work 語譯為「集合著作」，但因我國著作權法並沒有集合著作的用語，只有編輯著作的概念，故雖然著作權法是將編輯著作翻譯為 Compilation Work，此處還是將 Collective Work 一併譯為「編輯著作」，以表彰此種著作型態其在著作權法上受獨立保護的地位。
註四：德國著作權法第 9 條，其官方提供的正式英文譯文為，”Article 9 Authors of compound works: Where several authors have combined their works for the purpose of joint exploitation, each may require the consent of the others to the publication, exploitation or alteration of the compound works if the consent of the others may be reasonably expected in good faith.”。該條德文原文內容為，”§ 9 Urheber verbundener Werke: Haben mehrere Urheber ihre Werke zu gemeinsamer Verwertung miteinander verbunden, so kann jeder vom anderen die Einwilligung zur Veröffentlichung, Verwertung und Änderung der verbundenen Werke verlangen, wenn die Einwilligung dem anderen nach Treu und Glauben zuzumuten ist.”
註五：更多關於自由開源軟體在台灣著作權法架構上的相關分析，可參閱拙撰，國際自由開源軟體法律參考書台灣專章：http://lucien.cc/doku/doku.php?id=essays_and_articles:the_international_free_and_open_source_software_law_book-taiwan_chapter:translation_version。而關於電腦程式在德國著作權法上所示用的態樣及相關分析，可參閱：Tim Engelhardt/Till Jaeger, Germany Chapter in: The International Free and Open Source Software Law Book (IFOSS Law Book), available at: http://ifosslawbook.org/germany/ (Retrived April 29, 2014)。
~~~~~~~~~~ 本文結束 ~~~~~~~~~~