#モデル契約書の沼　ソースコードの引渡しを巡る攻めと守りの契約書（前編）

【関連】ソースコードの引渡しを巡る攻めと守りの契約書（後編）

１　はじめに

［ソースコード］［引渡し］［判例］でこのページにたどり着いた皆様。
あるいは、大阪地判平成26年6月12日（全文を表示。裁判所HPに移動します）以外の裁判例をお探しの皆様。
こんにちは。

ベンダ・ユーザの関心事の１つとして「ソースコードを引き渡してほしい／引き渡したくない」という点があります。それでは、どのような場合にソースコードを引き渡さなければいけないでしょうか（「引渡し」と「開示」については、文末脚注＊１）。

結論は、
「契約書の納入条項の定め方次第である。【攻】引き渡しを求める場合は納入条項に『ソースコードを納入する』と明記しておく。【守】引き渡さない場合は納入条項に『オブジェクトコードに限り納入する』と明記しておく。なお、著作権がどちらにあるかとは直接の関係はない。」
という回答です。

今回も、システム開発契約において参照されることが多い、経済産業省の定めた「モデル契約書」の条項例とともに検討してみたいと思います。

【契約書】経済産業省「モデル契約書」・第26条（納入物の納入）
１　乙は甲に対し、個別契約で定める期日までに、個別契約所定の納入物を検収依頼書（兼納品書）とともに納入する。
２　甲は、納入があった場合、次条の検査仕様書に基づき、第 28 条（本件ソフトウェアの検収）の定めに従い検査を行う。
３　乙は、納入物の納入に際し、甲に対して必要な協力を要請できるものとし、甲は乙から協力を要請された場合には、すみやかにこれに応じるものとする。
４　納入物の滅失、毀損等の危険負担は、納入前については乙が、納入後については甲が、それぞれこれを負担するものとする。

この結論は、モデル契約書でも（倒産時の文脈ですが）言及されています。

【参考文献】経済産業省「モデル契約書」・17頁
「倒産における著作権の帰趨については、対抗要件を具備する制度は存在しないものの、ソースコードや付帯するドキュメントの開示・交付を受けることは、納入物にソースコードを明記するか、エスクロウ制度の活用により対応可能である。 」

なお、表題を【契約書の沼】から「＃モデル契約書の沼」に改題しました！
理由はモデル契約書を主な検討対象にしているからです。ただし、その他の契約類型でも十分に参考になる議論かと思います。

２　前提：ソースコード、オブジェクトコードとは？

本題に入る前に、まずは、本稿で用いる「プログラム」「ソースコード」「オブジェクトコード」という言葉について私なりの理解を図示したいと思います。
下記は、「1+2」について計算式と結果を表示するプログラムです。実行すると「1+2=3」と出力されます。

■１　機械語、アセンブリ言語、高水準言語
◆１　機械語
機械は、ゼロとイチしか認識できないというのは有名な話だと思います。
機械語（マシン語）とは、コンピュータが理解（処理）できる言語です。
この言語で記述されたコードを、オブジェクトコード（ネイティブコード）といいます。

◆２　アセンブリ言語
上図の機械語をご覧ください。人間が機械語を記述することは極めて困難です。そこで、機械語を人間でも分かるように、簡略化した英単語や記号で、１対１に対応させた言語がアセンブリ言語です。この言語で記述されたコードを、ソースコードといいます。
上図を見ると「PUSH」や「MOV」などの表現があり、機械語と比べてずいぶん馴染みやすい印象を受けますね。ただ、人間には理解しやすくなりましたが、アセンブリ言語を機械は理解できませんから、それを機械が理解できるようにするために「アセンブル」という作業が必要です。

◆３　高水準言語
上記の「アセンブリ言語」は、実は、機械語と同様、「CPU」「メモリ」「レジスタ」等の制御について各機械ごとに理解する必要があります。
そこで、コンピュータの細かな制御を熟知していなくても使える「高水準言語」 が誕生しました。これは、人間の言葉に近い構文で記述できるプログラム言語です。この言語で記述されたコードを、ソースコードといいます。
現在、プログラム言語とされているもののほぼすべてが、この高水準言語に属します（C, C++, Perl, Java, Python, FORTRAN, COBOL,C#など無数）。高水準言語は人間が理解できる言語ですので、これを実行するには、機械が理解できる形式に変換する必要があります。この作業を「コンパイル」といいます。

■２　著作権法における「プログラム」
著作権法2条1項10の2号は、プログラムとは「電子計算機を機能させて一の結果を得ることができるようにこれに対する指令を組み合わせたものとして表現したもの」と定義しています。
この著作権法上の定義から、プログラムは、①低水準言語（機械語やアセンブリ言語）、②高水準言語のどちらも含む概念といえます。

以上について、中山教授は、次のとおり整理しておられます。

【文献】中山信弘「著作権法＜第2版＞」(2014年・有斐閣)・118頁
「直接オブジェクト・プログラムを作成した場合はそれ自体が著作物となるが、まずソース・プログラムが作成され、それがコンパイラーで変換されたオブジェクト・プログラムは、ソース・プログラムの複製となる。実際は、ある一つのプログラムであってもコンパイラーの種類によって異なったオブジェクト・プログラムともなり得るし、またコンパイラーの中のライブラリーの一部がオブジェクト・プログラムに入り込むこともありうるので、必ずしも一対一対応になっていないが、それでもその程度の範囲であれば通常は複製と考えられている。」

■３　例えるならば・・・
「オブジェクトコードとソースコード。どちらでもいいんじゃない？」と思われる方もいるかもしれません。
当該プログラムのソースコードがあれば、（法律論は抜きにして）自由に改変できます。しかし、ソースコードがなく、オブジェクトコードしかなければ、自由に改変することは非常に困難と言われています。上図のように、逆コンパイル（逆アセンブル）もできますが、完璧に元のソースコードを再現できる訳ではありません。

ソースコードの有用性を例えると・・・

・WORDファイルとPDFファイル。
・Ai（Adobe Illustrator）ファイルとPNGファイル
の関係に似ているかもしれません。
WORDファイルやAiファイルがあると、改変するときに便利です。

３　著作権の帰属とは無関係

■１　プログラムの著作権は誰にあるのか
著作権は、原則として、その著作物を創作した方に帰属します。
ただし、職務著作という例外があります（著作権法15条2項）。従業員が仕事で作ったプログラムについては、会社に著作権が帰属することが多いといえます。

そして、著作権者は、自ら著作物を自由に利用することができます。
それだけでなく、①第三者に譲渡したり、②第三者に利用許諾（ライセンス）することもできます。

■２　著作権者による権利侵害への対応
著作権者は、第三者が自己の著作物を勝手に利用している場合に、第三者に対して、差止請求や損害賠償請求をすることができます。しかし、著作権者は「引渡し」を求めることまではできません。

【文献】中山信弘「著作権法＜第2版＞」(2014年・有斐閣)・25頁
「情報はひとたび公開されてしまえば、第三者は何時でも、どこででも、かつ量的に限界なく利用できることになる。裏からみれば、情報についてはその利用の独占性は他の者の利用を禁止すれば維持されることになる。他方、他人に知られてしまった情報は、その他人の頭から消去することはできず、回収ということに意味がない。それゆえ、著作権法や特許法は所有権的構成を採用してはいるが、占有回収の訴えは規定されていない。回収に代替する処置としては、他人の行為を禁止すれば足りることになる。」

著作権は「情報（無体物）」に対する権利です。
情報は「モノ（有体物）」とは異なり、複数名が同時に利用できるという性質を持っています。そのため、著作権者といえども、情報の引渡しを求めることはできないのです。言い換えますと、著作権者だからといって、無体物（デジタルデータ）であるソースコードの引渡しを求めることができる訳ではないのです。
繰り返しますが、著作権とソースコードの引渡請求権は、直接の関係はありません（ただし、後述のとおり、著作権譲渡の合意があることを理由に、システム開発契約上の義務としてソースコードの引渡義務まで肯定される場合はあり得ます）。

小括
・著作権者だからといってソースコードの引渡しは求めることができない。
・ソースコードの引渡義務の有無は、納入条項の問題である。

４　ソースコードの引渡義務は契約解釈の問題

■１　契約書の納入対象に具体的記載がある場合

【例１】システム開発契約書・第ｘｘ条（成果物の納入）
「乙（ベンダ）は、甲（ユーザ）に対し、2020年●●月●●日までに、成果物を納入する。成果物のうちプログラムについては、オブジェクトコードのみを納入するものとし、甲（ユーザ）の指定するメディアに記録して交付する方法とする。」

上記【例１】では、「オブジェクトコード」のみの納入が合意されています。
この場合には、ソースコードまで納入する必要はありません。

【例２】システム開発契約書・第ｘｘ条（成果物の納入）
「乙（ベンダ）は、甲（ユーザ）に対し、2020年●●月●●日までに、成果物を納入する。成果物のうちプログラムについては、オブジェクトコード及びソースコードを納入するものとし、甲（ユーザ）の指定するメディアに記録して交付する方法とする。」

上記【例２】では、「ソースコード」の納入が合意されています。
そのため、著作権がベンダ・ユーザのどちらにあるのかを問わず、ベンダは、ユーザに対して、「ソースコード」を引き渡さないといけません（文末脚注＊２）。
もしも、ベンダがソースコードの引渡しを拒否した場合、ユーザは、裁判により、引渡しを求めることができます。

■２　契約書の納入対象に具体的記載がない場合

【例３】システム開発契約書・第ｘｘ条（成果物の納入）
「乙（ベンダ）は、甲（ユーザ）に対し、2020年●●月●●日までに、成果物を納入する。」

上記【例3】の「成果物」とは、製作依頼を受けたプログラムのことです。
次に、「成果物を納入」とあります。
しかし、具体的に、［何を］納入すればいいのか、指定がありません。このような場合、ソースコードとオブジェクトコードのどちらを納入すれば、義務を履行したことになるのでしょうか。

◆１　そもそも「引渡し」とは
システム開発における成果物たるプログラムの納入を、民法の条文に則して表現すると「仕事の目的物の引渡し」になります（改正民法633条参照）。ここでいう「引渡し」とは、「一般に仕事の目的物の占有を請負人（※ベンダ）から注文者（※ユーザ）に移転することを指す」とされています（山本豊編「新注釈民法14」有斐閣・2018年・181頁。※は菱田注）。

◆２　有体物と無体物の違い
たとえば、絵画（有体物）を引き渡す場合、絵画そのものを手渡すことによって、「物」の支配をを移転できます。しかし、プログラムは無体物であり、占有の移転が観念できないのです（メディアに記録して渡すことは「複製物」の移転です）。プログラムが無体物であるという点で、「納入（引渡し）」についての考え方が、絵画等の有体物とは異なってくるのです。

◆３　具体的検討
具体例で検討してみましょう。
例えば、ベンダがソースコードを記述したとします。
ソースコードの納入方法として、例えば、下記のパターンが考えられます。
①　クラウドなどにアップロードして引き渡す方法（複製・公衆送信）
②　ＤＶＤなどのメディアに書き込んで引き渡す方法（複製）

しかし、どちらも著作物たるソースコードの複製物を納入しています。
ソースコード自体は無体物なので、原則、何らかの複製行為を介さなければ納入できないのです（ただし、客先のＰＣで直接コーディングした場合など限定的な場合には、ソースコード自体を納入できる余地があります。改正民法633条ただし書も参照）。

さらに、オブジェクトコードでも考えてみましょう。
ソースコードをコンパイルしたオブジェクトコードは、ソースコードの複製物です。このオブジェクトコードを納入する場合にも、上記同様に、①クラウドなどにアップロードする方法や②ＤＶＤなどのメディアに書き込んで納入する方法があり得ますが、これらも、やはり複製物を納入していることになります。

つまり、プログラムの場合、オブジェクトコード又はソースコードいずれも、原則として、複製物の納入しか出来ないのです。そして、どちらの納入であっても、契約目的であるプログラムの「成果物の納入」が実現できるのです。

◆４　本題（契約書に納入対象について記載がない場合）
それでは、本題にはいりましょう。
「成果物を納入」としか記載がない場合には、ソースコードとオブジェクトコードのどちらを納入すれば、義務を履行したことになるのでしょうか。

この条項でいう「成果物の納入」とは、製作の依頼を受けたプログラムを納入することです。そして、
①オブジェクトコードの納入であっても契約目的であるプログラム納入が実現できること
②明示的（意図的）にソースコードと指定されていないこと
からすると、この契約書の文言のみからの判断では、私見ですが、ソースコードとオブジェクトコードのどちらを納入しても、契約目的は達成したことになります。

◆５　契約書に解釈の余地があることには注意
ただし、契約書の文言解釈（契約書をどう読むのか）については、重要な注意事項があります。それは、契約書の文言を解釈するにあたっては、従前の当事者間のやりとり等の背景事情が考慮されるということです。
具体的には、①ソースコードを引き渡すことが前提となっているメール等のやりとり、②ユーザが自身での保守を望んでいる事情の有無、③著作権を譲渡するとの合意条項の存在、④業界の慣習等の事情があれば、当事者間では「成果物の納入」とはソースコード自体の引渡しまでも意味すると解釈される場合もありうるでしょう（さらに、いわゆる「完全合意条項」がある場合は別の考慮が必要です）。

それでは、裁判例をみてみましょう（続）。
#モデル契約書の沼　ソースコードの引渡しを巡る攻めと守りの契約書（後編）

執筆者：
STORIA法律事務所
弁護士　菱田昌義（hishida@storialaw.jp）
https://storialaw.jp/lawyer/3738
※　執筆者個人の見解であり、所属事務所・所属大学等とは無関係です。

５　補遺・脚注

補遺・脚注は後編に記載しています。