台灣智財法與開源模式的潛在衝突

在⟨開源軟體與著作權的光譜⟩一文中，已初步釐清開源軟體實際上仍受智慧財產法保護。至於保護的程度與強弱，則需要從授權條款分析。然而，授權條款多半以英文撰寫，與國內的智財法未必相容。因此，這篇文章的內容會偏向法律分析，嘗試將開源領域的概念與台灣智財法概念進行耦合，並作為授權條款分析的基礎。

若是無法律研究需求的開發者，可以直接閱讀小結的段落即可。

版本貢獻、分支專案的法律性質爭議

如我在⟨開源軟體與著作權的光譜⟩一文提到，開源的重點核心在於「集思廣益」，透過眾人之力，將程式碼逐步修正至完美，而逐步些正的過程便創造出各種後續版本。然而，參與貢獻的態樣非常多，可能是原作者與貢獻者共同參與開發與修正；也可能是貢獻者獨立開發、修正，再提交給原作者。甚至貢獻者直接將專案分支，基於原專案的基礎自己獨立開發。

如此多變的合作樣態如何函攝至智財法上？這裡爭議還不少，以下先以著作權法為主要分析的對象。

將版本貢獻、分支專案定位為「衍生著作」

如果觀察各種開源軟體授權條款內容，可以發現多數授權條款都會用到「subsequent」、「derivative」等字形容基於原專案原始碼所生的後續改良品。因此很容易將之翻譯為「衍生」，並與著作權法上的「衍生著作」進行連結。

但衍生著作有其法律定義上的限制，其中最重要的就是，是否有其他「創意」在內？如果沒有額外的創意，就不符合「改作」的定義，產生的作品也就不會是衍生著作。舉個易懂的例子－原著小說與改編電影。改編電影是以原著小說的劇情為基礎，進行劇本的編寫與畫面的拍攝，這當中便含有編劇與導演的巧思，因此改編電影屬於原著小說的衍生著作。假設某人只是將紙本的原著小說變成可用電腦螢幕觀看的電子檔，由於沒有額外的創意與思考，便不會成為衍生著作。（但仍涉及重製行為）

同理，如果版本貢獻、分支專案有納入貢獻者自身的思想與創意，則在法律上可定位為衍生著作。但如果只是修正一些臭蟲(bug)，如補上遺漏的終結符號（語法錯誤），或是修正變數型態（邏輯錯誤），這種貢獻依然有其價值，但可能無法成為法律上的衍生著作。

衍生著作，在著作權法上便將之視為獨立的著作、享有獨立的著作權，且與原著作相互獨立、互不干涉。只是合法的衍生著作必須在創作前取得原作者授予的「改作權」，如同改編電影導演須事先取得原著小說家的同意。

將版本貢獻、分支專案定位為「編輯著作」

若貢獻者僅是修正一些臭蟲(bug)，並沒有另外加入新功能，或以不同方法解決問題，本質上沒有額外創意的成分，而不構成「改作」，其作品也非「衍生著作」，但可否成為「編輯著作」？

編輯著作是對於原著作付出「苦勞」，常見例子如詞曲合集或論文集，編者對原作者的文章進行篩選及排序而不更動原文內容，如果篩選或排序具有編者自身的創意成分，著作權法仍然給予編輯著作獨立的著作權保護。

因此，由上述定義可以發現，修正臭蟲(bug)本身就是對原著作進行修改，恐怕也難以成為編輯著作。

一個有趣的問題是，如果有人對原始碼進行「coding style」的修改（如增加縮排、變更字型顏色或改變函式擺放的順序），是否構成編輯著作？本質上並未變動原著作，而僅將其表達以更易讀的方式進行排版，似乎符合編輯著作的定義。但實務上，僅僅「coding style」的修改大概無法成為有貢獻的版本，也沒有對其進行法律定位的必要。（此部分尚涉及程式的功能、表達、是否具著作性的爭議，已超越本文欲探討的範圍，故不在此討論）

將版本貢獻、分支專案定位為「共同著作」

接續開源的核心精神，集思廣益本質上就是一群人一起努力、一起創作。那開源軟體是否可定位為「共同著作」？

如果原作者與貢獻者彼此有就修正內容進行意見交換，則將貢獻版本視為原作者與貢獻者的「共同著作」沒有爭議。但若是貢獻者獨立修改再提交給原作者審核，由於貢獻者與原作者欠缺明確的事前溝通協調，傳統上恐難以認定貢獻者與原作者具有共同創作的主觀意思。有人認為可以援引授權條款作為預先協調的依據，從而使貢獻者與原作者成為共同著作人。這種解釋固然可以解決前面修正臭蟲(bug)無法構成衍生著作的問題，但仍然會面臨權利行使上的困境。

這是因為共同著作的財產權是由全體共有人共同行使，容易造成原作者權利行使上的不便。雖然著作權法第40條之1有「無正當理由不得拒絕同意」的但書規定，然而「正當理由」本身就是不確定法律概念，必須由法院斷定，但要原作者循漫長的司法途徑才能伸張權利，必將大幅削弱原作者敞開心胸讓大家集思廣益的誘因。

此外，若貢獻者直接將專案分支，以自己的名義對修正內容負責而不提交給原作者審核，這種情況要定位為共同著作便有困難。

小結：未修法前應「類推適用」衍生著作

由上面的分析可知，目前台灣著作權法下，並沒有一個完全符合開源模式的規範框架。

我認為若將版本貢獻、分支專案定位為共同著作，反而會降低原作者開源的誘因。因此，我傾向以法律漏洞的方式處理，將版本貢獻、分支專案類推適用衍生著作，這樣可以避免原作者權利行使上的困擾。但正本清源之道，還是必須修法增加符合開源模式的類型。

我後續的相關文章都會以衍生著作、衍生作品稱呼這些版本貢獻或分支專案。

「copyleft」與著作權法上「再授權」的差異

處理完原作者與貢獻者之間的合作問題後，還必須處理貢獻者與後續其他貢獻者之間的問題，也就是「copyleft」。copyleft 的概念就是開源定義中「衍生作品應依同一授權條款再散布」。

但這與著作權法或專利法中的「再授權」(sublicense)又不太一樣。

舉例

Jack撰寫了一個開源專案A，並採用 GPL-3.0 授權，因此Mary可以對A專案進行優化改良，改良後的衍生作品稱為B專案。而根據 GPL-3.0 授權條款第5條，B專案也必須採用 GPL-3.0 授權。

雖然在 GPL-3.0 授權條款第5條並未使用「copyleft」一詞，但由於 GPL類授權是由開源提倡者 Richard Stallman 草創，其運作模式就是「copyleft」的代表。Mary依據A專案的 GPL-3.0 授權條款規範，必須將其改良的B專案也以 GPL-3.0 授權條款釋出。

然若Jack不是採用 GPL-3.0 授權，而僅採用著作權法上的授權，且Mary獲得「再授權」的權限，則Mary本身可以運行A專案或對A專案進行修改，也可以將A專案「再授權」給其他人運行、修改。但Mary所改良出的B專案則不在「再授權」範圍內。換句話說，Jack的授權自始至終都只跟A專案有關，而不涉及衍生的B專案。

分析

會有這種差異是因為台灣的著作權法認為「衍生作品」也是一種獨立的作品，也有獨立、完整的著作權。只是衍生作品生成之前，必須先取得原作者授予「改作權」。獲得改作權而產生的衍生作品便不再受原作者控制，轉由改作人決定衍生作品的一切授權事項。（因此有人將採用此模式的 Apache 授權稱作「轉授權」，但我認為容易使人誤會衍生作品的著作權是自原作者「轉手」而來）

那在著作權法下，是否有「copyleft」的概念呢？目前是沒有直接對應的規範。

但可以解釋成原作者授予改作與散布權時所附加的「解除條件」。意即，原作者授予貢獻者改作權與散布權，但若貢獻者改作後散布的衍生作品沒有依同一授權條款繼續授予其他人改作權，則原作者本來授予的改作權便失效，使衍生作品成為違法的著作，驅使貢獻者繼續授予後續貢獻者相同的附條件改作權。

小結：「copyleft」不等於「再授權」

總而言之，在詮釋「copyleft」的時候，不宜使用「再授權」一詞，避免與著作權法第37條第3項規定中的再授權混淆。有人主張應將「copyleft」譯為「授權拘束性」，但為了保險起見，後續的相關文章我仍使用開源定義中的原文「衍生作品應依同一授權條款再散布」表示「copyleft」。