所謂的受雇人，簡單來說，就是在一間公司或組織聘用來在負責一定職務工作的員工，因此受雇於一間公司來專職開發軟體、韌體的工程師，就是受雇人，而該公司就是雇用人（註一）。若是這間公司利用 GPL 元件來開發產品，軟體工程師可以自由散布產品程式碼嗎？工程師在產品中所撰寫開發的程式碼，其權利是屬於工程師本身、還是該公司？這些疑問是受雇軟體工程師在利用自由開源軟體來開發產品時，可能會產生的，因此本文將先從著作權法相關的規定談起，並且說明實際雇傭關係的運用狀況，進而釐清這些可能的疑問。

 

 

【著作權的創作保護主義】

 

我國的著作權法與許多其他國家一樣，是採用「創作保護主義」來作為判定著作權歸屬的基本原則，也就是當一個作品在創作完成的同時，創作人自動成為著作人，而成為著作人的代表者可以享有著作權法所賦與的各項權利，這些權利包括了著作財產權與著作人格權兩類。

 

所謂的著作財產權，就是我們日常生活耳熟能詳的重製、散布、改作等傳統的著作權權利，此外，近數十年才納入到著作權法中的公開播送、公開上映、公開口述、公開傳輸等等權利也是屬於著作權財產權。由於這些財產權的運用可以讓著作人產生相對直接的金錢利益，所以被劃歸為一個類別來規定（註二）。

 

相對於著作財產權，著作人格權的重點在於保護著作人的人格跟聲譽，並非與金錢利益直接相關，因此獨立一類來加以規定。在著作人格權中，最為常見的應該要歸「姓名表示權」莫屬，像我們在書籍、圖畫上會看到作者、畫家的筆名、別名，在雕塑作品旁可以看到創作者的姓名，這些都是姓名表示權的一種實踐方式。另外，還有一個被廣為運用，但是鮮少人知道的著作人格權是「公開表示權」，顧名思義，這個權利讓著作人有權來決定是否、何時以及採用什麼樣的形式來公開自己著作的權利，所以像是出版書籍、展出畫作、將文章公開在網路上等等，都是屬於公開表示權的實際行為（註三）。

 

【雇傭關係的例外規定與實務運作】

 

不過上述的創作保護主義只是原則，在著作權法中還規定有例外的狀況。而針對本文主軸的雇傭關係，著作權法第 11 條就有非常明確的例外規定，最主要的規定是在該條的第 1、2 項中：

 

- 第 1 項：「受雇人於職務上完成之著作，以該受雇人為著作人。但契約約定以雇用人為著作人者，從其約定。」

 

- 第 2 項：「依前項規定，以受雇人為著作人者，其著作財產權歸雇用人享有。但契約約定其著作財產權歸受雇人享有者，從其約定。」

 

這兩項規定出三種狀況：

 

1、員工與公司透過契約，將職務上著作的著作人直接約定為公司，這時候著作的所有權利皆歸公司享有，員工若需要利用這個著作，必須另外取得公司的同意；

 

2、員工沒有與公司另有任何的相關約定，因此員工因為著作權法第 11 條第 1 項的規定直接成為職務上著作的著作人，但是這些著作的著作財產權仍然直接歸公司所享有，在這種情況下，公司可以直接販售著作、將著作進行商業化利用，而不需要另外取得創作員工的同意，不過在此同時，員工仍然擁有著作人格權可以來運用，例如：仍然可以向公司要求在其所創作的著作上標示姓名或筆名；

 

3、員工與公司另訂契約，約定著作財產權歸員工所享有，這時候員工對於其職務上所創造的著作享有完整的著作權利，公司若是想要運用這些著作的話，必須另外取得員工的同意。

 

上述三種狀況在資通訊產業的實務運作裡，以第 3 種最為罕見，其次第 2 種的狀況也不多見，最普遍的是第 1 種，也就是一般資通訊產業的公司都會與員工約定，讓公司自始就取得著作人的地位，以方便未來直接運用這些員工所創作出來的著作，例如：將工程師所撰寫的韌體在入到嵌入式裝置中，在將裝置販賣到消費市場上；收取授權金後，允許其他公司來利用工程師所開發出來的軟體；或者將工程師所開發的程式碼，直接轉賣給其他公司等等。這類約定條款存在的形式，可能是直接寫進雇傭契約中，成為契約本文的一部份，不過更多時候是以一份獨立的智慧財產權指定附加條款的形式存在，員工在簽署雇傭契約之後，另外再簽署這份附加條款，在契約與附加條款中也會同時敘明，這份附加條款屬於整體僱用契約的一部份，受雇員工同樣受到此附加條款內容所約束。

 

【相關的著作權歸屬與運用疑義解析】

 

在了解現在著作權的相關規定與實務運作之後，接著我們回過頭來看看本文一開頭所提出的疑問，以下本文採用擬問答的方式，逐一說明這些問題。

 

1、工程師利用自由開源軟體開發公司產品，這些工程師在工作職務範圍內所開發出來的程式碼，著作權歸屬於誰？公司、還是工程師？

 

由於一般的狀況下，公司與工程師皆會另外以契約約定著作人就是公司，這時候就應該以契約約定為準，工程師所開發出來程式碼因此皆屬於公司所有，公司因此擁有這些程式碼完整的著作財產權與人格權。

 

在少數沒有另外約定的情況下，工程師擁有其所自行開發的程式碼，只是由於著作權法規定，產品著作財產權仍然是直接歸屬公司所有，因此實際上，工程師可以利用的程式碼著作權只剩下人格權部份。

 

而只有在極為罕見的情況下，工程師與公司會有另外的約定，讓工程師享有著作財產權，在這時候工程師就是其所撰寫程式碼的完整著作人，同時享有著作財產權與人格權。

 

2、呈上題，若是利用 GPL 元件開發公司產品，由於 GPL 規定使用者必須公開源碼，在產品還沒有出貨或上架到消費市場的情況下，工程師若是未經公司同意，就自行將程式源碼公開出來，是否會與公司產生法律糾紛？

 

首先需要說明的是，GPL 沒有規定使用者必須「公開」所取得程式的源碼，而是規定使用者一旦散佈 GPL 程式的時候，必須「提供」程式源碼給取得程式的後手，也就是提供源碼這項義務是透過「散布行為」來啟動的。若程式僅在公司內部利用，並不會被認定是散布行為，這時候公司與工程師也都沒有義務要將 GPL 程式的源碼提供給他人。

 

不過若是工程師因為認同自由開源軟理念，仍然想要主動將產品程式源碼公開釋出，或者回饋給自由開源軟體社群的話，這時候就要看工程師本身是否有權來做這個決定。有權主動散布程式源碼的人，是擁有程式碼著作財產權的人，因此回歸到本文之前說明過的內容，除非工程師與公司之間有另外約定由工程師享有著作財產權，否則原則上這些程式碼的著作財產權都歸公司所享有，因此若是工程師想要散布產品的程式源碼，就必須另外取得公司的同意，若未取得公司同意逕行散布，就會違反與公司所訂定的契約或構成對公司著作財產權的侵害。

 

3、呈上，身為認同自由開源軟體的工程師，到職時也簽署了附加條款，將公司指定為工作上所開發出來程式碼的著作人，這時候若還是想將包含有 GPL 元件的產品源碼公開釋出，應該要怎麼做？

 

由於這時候工程師本身並沒有合法的權利可以釋出源碼，所以能做的就是與相關的主管溝通，讓其了解之後，由公司來釋出源碼。

 

若是產品已經出貨或上架到消費市場上，卻沒有附隨提供 GPL 程式源碼，這時候的公司已經處於一個侵權的狀態，因此工程師可以跟公司的相關主管說明 GPL 的義務規定，並請其提供產品中 GPL 部份的源碼，以避免未來發生侵權糾紛，造成公司額外的金錢損失；但若是產品仍處於研發階段，此時公司並沒有強制釋出源碼的義務，但是對於一些公司來說，在研發階段將產品程式源碼釋出，然後與開發社群一同維護所釋出的源碼，的確可以省下內部除錯與更新的重複工作，所以可以針對這點與相關主管討論，也許在研發階段就釋出源碼，對公司整體來說反而是一個有利的模式（註四）。

 

【可將工程師納入產品貢獻清單中】

 

在現行著作權法的規定與實務運作下，受雇人在職務上所創作出來的著作大多由公司取得著作財產權，因此有心想要釋出或公開產品程式源碼的工程師，通常難以逕行為之，而必須要轉以與相關負責主管溝通的策略，讓公司了解 GPL 的義務規定或協同開發的優點，這時才有機會順勢而為釋出產品程式源碼。

 

此外，雖然常見的實務運作，是約定公司為職務上著作的著作人，但是筆者建議工程師可以爭取將自己的姓名或網路暱稱代號標示在源碼中，隨著產品源碼釋出時一同散布出去。這樣的標示對於工程師來說，是一個可以彰顯其個人聲譽與技術能力的方式；而對於公司來說，產品源碼中若清楚標示那個檔案是由那位工程師所負責，未來若有其他開發者對於源碼有疑問的話，就可以直接聯絡該位工程師，進而減少公司客服處理、轉達這類問題的工作。而在工程師與公司間並沒有相關智慧財產權約定的情況下，由於工程師仍保有人格權，所以其不但可以要求將姓名或網路代號標示在產品源碼中，甚至未包含源碼的產品也可以要求標示上姓名或代號。因此雖然在大部分的情況下，公司享有產品程式碼的著作財產權，但是對於工程師來說，仍然可以朝向姓名標示的方向來與公司溝通，也許可以因而達成一個對工程師個人聲譽有幫助，同時也能減少公司處理來自外部技術詢問的有益模式。

 

----

 

註一：讀者可能也會看到有文章採用「受僱人」與「僱用人」，這是因為「僱」與「雇」二字被混用在不同的法律條文中所導致，例如民法是採「僱用人／受僱人」，但是著作權法卻是「雇用人／受雇人」，不過這兩組用詞在法律上並沒有特別的差別。由於本文主要是在討論著作權法的規定，因此內文採用「受雇／雇用」，在此先予說明。

 

註二：我國著作權法對於財產權的規定在第 22-78 條，共 57 個條文，是我國著作權法最主要的部份。

 

註三：我國著作權法對於人格權的規定是在第 15-21 條，其中第 15 條規定公開發表權、第 16 條規定姓名表示權。而除了文中介紹的兩個著作人格權外，我國著作權法還規定有「同一性保持權」，或者又稱為「禁止不當修改權」，這個權利是透過保護著作特質的一貫性，來達到著作人的人格與名譽不受到損害的目的。舉例來說，若是有人在沒有經過作者的同意下，就任意在其小說中加入色情描述文字，並且將修改過的內容透過網路散布出去，導致有讀者誤認這個小說作者的寫作傾向於情色風格，這樣的行為可能就是侵害了這位小說作者的同一性保持權。

註四：關於本文所列的這些問題，GNU 計畫在其所維護的 GPL FAQ 中有獨立的一個問題來加以說明：https://www.gnu.org/licenses/gpl-faq.html#HowIGetCopyright。這個英文問答內容的中文翻譯可以參考：林誠夏，

https://lucien.cc/doku/doku.php?id=notes_and_translations:frequently_asked_questions_about_the_gnu_licenses#%E6%88%91%E8%A6%81%E5%A6%82%E4%BD%95%E8%A8%BB%E5%86%8A%E8%87%AA%E5%B7%B1%E7%A8%8B%E5%BC%8F%E7%9A%84%E8%91%97%E4%BD%9C%E6%AC%8A_%E4%BB%A5%E4%BE%BF%E5%B0%87%E5%85%B6%E4%BB%A5gpl%E6%8E%88%E6%AC%8A%E6%A2%9D%E6%AC%BE%E5%90%91%E5%A4%96%E9%87%8B%E5%87%BA%E5%91%A2

。