程式碼的著作權歸屬何人所有

在日本的著作權法中，程式碼明確地被視為「著作物」。

然而，與小說或繪畫等著作物不同，通常來說，系統開發相關的程式碼是由多名員工或多個法人組織合作創建的。

因此，權利關係往往變得模糊，很容易演變成複雜的爭議。

因此，在本文中，我們將解釋程式碼的著作權歸屬誰所有這個問題，並針對容易引起爭議的點和解決方案，結合判例進行說明。

何謂著作權法

日本的著作權法是一項旨在保護小說、電影、繪畫等著作物作者的權利，並為創作提供激勵，以此「促進文化的發展」的法律。

另外，著作權法的特點之一是，與專利法等不同，不需要在國家進行註冊等行為，當創作出著作物時，權利就自然產生。

「程式碼著作物」與「源碼」的關係

在日本的著作權法中，與小說或繪畫等一樣，「程式碼」被視為「著作物」，並明確在法律上列為著作權法的保護對象（日本著作權法第10條第1項第9項）。

第十條（著作物的示例） 以下是該法律所稱的著作物的示例。 … 九 程式碼著作物 日本著作權法第10條第1項第9項

另外，「程式碼」被定義如下：

將電腦指令組合在一起，使其能夠達到特定結果的表示。 日本著作權法第1條第1項第10項的2

另一方面，「源碼」雖然並未在法律上有明確的定義，但通常被理解為人類以特定語言（如 JavaScript、Python 等）對電腦下達的指令。

電腦通過將此源碼轉換（編譯）為機器語言，執行這些指令。

因此，根據「程式碼」的上述定義，源碼可被視為受到日本著作權法保護的「程式碼著作物」。

系統開發中可能遇到的著作權問題

在系統開發的場景中，涉及著作權的問題主要可以分為兩大類型。

誰會成為著作權者

著作權歸屬於誰，涉及到著作權轉讓的成功與否以及時間等問題。

在系統開發的場景中，供應商方通常會有許多工作人員分工協作進行項目，因此權利歸屬的主體往往變得模糊，容易引發複雜的爭議。

此外，在供應商向用戶交付成果物的過程中，也可能會有關於著作權是否可以轉讓等問題引發爭議。

關於源碼著作權歸屬的基礎知識

我將解釋有關著作權的基礎知識，包括著作權的歸屬，開發的轉移，契約等相關事項。

著作權原則上歸「創作的人」

首先，我們來整理一下著作權歸屬於誰的問題。在程序的情況下，就像小說或繪畫等著作物一樣，原則上，權利歸屬於著作人（創作著作物的人）。

但是，根據日本著作權法，如果符合職務著作的情況，則權利歸屬於法人等使用者。

根據法人等的發意，由從事其業務的人在職務上創作的程序的著作物的著作者，除非在創作時的契約，工作規則等有其他規定，否則應視為該法人等為著作人。 日本著作權法第15條第2項

也就是說，作為供應商員工在業務中創作的程序的著作權歸屬於供應商。

開發的委託並不意味著著作權的轉移

除了著作者人格權外，著作權是可以轉移或轉讓的權利。

但是，需要注意的一點是，支付報酬委託開發業務與著作權的轉讓是兩個不同的問題。

有一些情況下，由於支付了開發費用，所以會誤解為與交付一起，程序的著作權本身也被轉讓。

但是，著作權法上的原則是「權利歸屬於創作的人」，並不是「權利歸屬於負擔創作費用的人」。

因此，如果委託者希望獲得權利，則需要事先製作契約，並將該內容作為契約的內容進行確定。

關於契約等中的著作權轉讓條款的存在與否

關於著作權轉讓的協議，可以分為以下幾種情況：

• 契約書等中有關於著作權轉讓的規定的情況
• 沒有契約書的情況，或者契約書等中並未設定關於著作權轉讓的條款的情況

如果在契約書等中關於著作權轉讓有規定，那麼當然，可以從對方那裡接受著作權的轉讓。著作權是可以轉讓的權利，且著作權者自願承認了著作權的轉讓。

但是另一方面，如果沒有契約書，或者在契約書等中沒有設定關於著作權轉讓的條款，或者沒有關於著作權轉讓的明確協議，著作權是否可能被轉讓呢？

以下將根據關於著作權轉讓沒有明確協議的情況的審判例，解釋著作權轉讓的成敗。

肯定著作權轉讓的裁判案例

儘管系統開發與其略有不同的領域，以下的裁判案例可能會有所參考。

在關於火車站入口裝置的紀念碑設計的問題上，原告為該紀念碑設計的創作者，而被告為部分改變該設計並建立紀念碑的日本的縣及其縣託付業務的設計公司。爭議的是是否存在侵犯著作權的問題。

在此案中，原告與被告之間並無明確的著作權轉讓協議。被告們主張，因為原告事實上已經承認該設計的著作權屬於被告，並同意修改該設計，所以不應認為侵犯了著作權。

因此，在此案中，著作權轉讓的成敗成為爭點。對此，法院做出以下裁示：

這些事實（例如接受設計費的事實，以及沒有經過設計討論程序就同意進一步修改設計的事實等）以及，本案紀念碑是預定從一開始就設置在岐阜站的南入口，並沒有考慮到其他的用途，因此，控訴人在製作本案紀念碑時，在與被控訴人公司間，對於其提供的繪有紀念碑設計（該設計即為本案的著作物）的圖紙等，即使這屬於美術作品並受著作權保護，但他已經至少默示地同意將其著作權轉讓給被控訴人公司（被控訴人公司將根據上述業務託付契約，將所有著作權轉讓給被控訴人縣）。然後，他提出了關於上述紀念碑的設計提議，並以此作為對價，從被控訴人公司處得到了他要求的報酬，這是合理的認定（即使認為著作權轉讓的協議存在困難，控訴人至少默示地承認了被控訴人公司根據被控訴人縣的託付，採用了控訴人的一部分設計來進行本案紀念碑的設計工作，並且被控訴人縣根據此建立了本案紀念碑。這是他在提出上述紀念碑設計提議並得到對價的基本前提條件，這一點是明顯的）。 東京高等法院裁決2004年（日本的平成16年）5月13日

也就是說，即使沒有關於著作權轉讓的明確協議，也可以考慮業務執行過程中的各種情況，如果被認為著作權人已經「默示地同意」轉讓

確認源碼的著作權者的方法

這裡將會介紹三種確認源碼的著作權者的方法。

確定受爭議的程式的開發者

一個IT系統通常由許多程式組成，多人共同分工開發。因此，首先需要調查和確定受爭議的程式的開發者是誰。

在這種情況下，開發商的工作計劃中記錄的負責人名稱、源碼中附加的註解裡的創建者信息等，可能是重要的線索。

整理開發者和公司的關係

如前所述，如果屬於職務創作，著作權將歸屬於並非撰寫源碼的人，而是該人的使用者，即法人等。

如果程式的開發是在開發者所屬公司的指導和監督下進行的，則職務創作性相對容易被認定。

但是，另一方面，如果基於私人人際關係，例如“幫忙”的關係，可能會有爭議職務創作的適用性。

提前考慮著作權轉讓的協議

如果委託人聲稱從供應商那裡獲得了權利，那麼他將需要承擔證明責任。此外，著作權轉讓的成功與否是由當事人之間自由決定的事項。

因此，為了預先避免這種爭議，最好在委託系統開發階段就提前確定著作權的歸屬和轉讓，以及從供應商那裡獲得使用許可的範圍等，並在契約中明確表示。

請注意，所謂的日本經濟產業省模型契約，也就是公開的系統開発契約模板，有以下參考條款：

第45條（交付物的著作權） 關於交付物的著作權（包含日本著作權法第27條及第28條的權利），除甲方或第三者自前已擁有的著作物的著作權外，應歸乙方所有。 （以下略） 日本經濟產業省「信息系統·模型交易·契約書(委託開發(包含部分企劃)、維護運用)〈第二版〉」

※甲方為用戶，乙方為供應商。上述模板只是一個例子，將著作權歸屬於供應商，但也可能進行將著作權歸屬於用戶的契約。

結論：明確源碼著作權歸屬需透過契約等手段

關於系統開發的著作權歸屬爭議，透過提前製作契約可以防止。

然而，製作契約需要法律知識。如果你想在製作契約時提前避免問題，那麼請求擁有法律知識的律師會是安全的選擇。

如果你在著作權所有權問題上有困擾，請與本所聯繫。