プログラムにまつわる著作権侵害問題とは

「著作権問題」というと、デザイナーが手がけたロゴデザインやキャラクターデザインの剽窃の話などを真っ先に思い浮かべるという人も多いかもしれません。しかし、実はエンジニアが書いているコードも法律上「著作物」と扱われるものであり、著作権が認められます。

とはいえ同時に、エンジニア・プログラマの仕事は、一朝一夕に独創性を発揮できるということはなかなかなく、他者が考え抜いて作ってきたコードから多くを学ぶことによってはじめて、自身もまた生産的なアウトプットが可能となることも多いものです。

本記事では、著作物としてのプログラム・ソースコードに対して、「参考にする」ことと「盗用する」ことの線引きはどのようにして行いうるものであるかを解説します。

システム開発と著作権法はどう関係するのか

著作権法は何を保護し、何を保護しないか

そもそも著作権法とは何で、何のためにあるのでしょうか。実はその答えも、著作権法のなかに記されています。著作権法第一条、その冒頭には自身の存在意義として、次の内容が謳われています。(傍線部は筆者が追記したものです。)

第一条　この法律は、著作物並びに実演、レコード、放送及び有線放送に関し著作者の権利及びこれに隣接する権利を定め、これらの文化的所産の公正な利用に留意しつつ、著作者等の権利の保護を図り、もつて文化の発展に寄与することを目的とする。

著作権法第1条

すなわち、著作権者としての個人の権利を保護するとともに、それをいかにして社会全体の利益につなげ、全体として物事に調和をもたらすかという点を問題としている領域であるといえます。

また、法律上の著作権が及ぶものとは何かという話になれば、以下に引用する10条1項に例示がなされています。

この法律にいう著作物を例示すると、おおむね次のとおりである。

一 小説、脚本、論文、講演その他の言語の著作物
二 音楽の著作物
三 舞踊又は無言劇の著作物
四 絵画、版画、彫刻その他の美術の著作物
五 建築の著作物
六 地図又は学術的な性質を有する図面、図表、模型その他の図形の著作物
七 映画の著作物
八 写真の著作物
九 プログラムの著作物

著作権法第10条1項

同項9号には、「プログラムの著作物」とはっきりと記されてもいます。つまり、ソースコードにもやはり、著作権法は適用されます。これらはあくまで「例示」にすぎないので、ここに含まれるもののみが同法の適用対象というわけではありません。しかし少なくともプログラムが確実に同法の射程圏内にあることは明らかです。

著作権が認められているということの実質的な意味は、プログラムという文脈に即してなるべく端的に説明するならば、複製(同法21条)や、ネット経由での配信である公衆送信(同法23条1項目)、譲渡(同法27条)といった事柄について、特定の権利者のみが独占的に著作物を利用することができるということです。また、著作権を侵害された場合には、権利者は、民事的な措置として、差止め(著作権法112条1項)や、不法行為責任に基づく損害賠償請求(民法709条)を求めることができます。

もっとも先述の通り、著作権法は、権利者個人の擁護と、社会全体でみた場合の利益という、二つの価値のバランスをとることを目的とした法分野です。そうであるからには、その権利が及ぶ場合だけではなく、「著作権が及ばない場合」というものについても併せて知っておくべきでしょう。

たとえば既存のプログラムに関して、そのプログラムの著作権を有しない者が、あくまでユーザーという立場で、プログラムを実行したような場合、原則、著作権侵害にはあたりません(著作権法47条の8)。また、私的利用と認めらえる範囲内であれば、複製・翻案を行うことは違法とはなりません(著作権法47条の3)。

権利者の地位の保障が勿論重要であるなかでも、他人の創作物から刺激を受けて新たな創作物を生み出すこと、こうした積み重ねで成り立つものが、まさに「文化」でもあるでしょう。「盗用する」ことと「参考にする」ことの違いは何かという問題を根本に抱えながら、発展を続けてきた法分野だという言い方もできるかもしれません。

システム開発法務で、なぜ著作権法が大事なのか

ITシステムの開発やプログラムの実装といった仕事においても、著作権侵害の成否が争われた事案は、過去にも実際に起きています。”よく似た”二つのプログラムについて、それが「参考にしただけ」なのか「元々あったプログラムを盗用した」のかといった争いです。たとえば、もともとシステム開発会社に在籍した社員が、独立した後に、”よく似た”別のプログラムを実装して商品化したとしましょう。その際に、前職にあたるベンダー企業が権利を主張するというようなトラブルは十分起こりうるものです。

なお、こうした紛争が起こりうるということは、何も「盗用された」側だけでなく、「”盗用だ”と非難を受ける側」からみても深刻なリスクを含んでいます。この場合におけるリスクの最たるものとしては、差止請求権を交渉でちらつかされることが挙げられます。

「著作権」というものが「強い権利」である最大の理由は、いわゆる「差止請求権」が認められているという点にあります。

著作者、著作権者、出版権者、実演家又は著作隣接権者は、その著作者人格権、著作権、出版権、実演家人格権又は著作隣接権を侵害する者又は侵害するおそれがある者に対し、その侵害の停止又は予防を請求することができる。

著作権法第112条

著作権侵害の被害を受けた者は、侵害を行う者に対して、「停止」を請求することができます。つまり、例えば現に稼働しているサーバーサイドのプログラムが著作権侵害に該当する場合、そのサーバーの停止、すなわちサービス停止を請求することができるのです。

現に利益を生んでいるそのサービスについて、「利用は停止しないであげるかわりに、使用料の支払いに応じてほしい」などと交渉を持ちかけられるとしましょう。この場合、著作権侵害に抵触してしまっているという”弱み”から、世間相場と無関係な価格交渉を持ちかけられてしまうリスクがあります。ことさらに海賊版を作ってやろうなどという悪意がないエンジニアであっても、著作権の問題について無頓着でいることは、こうした意味である意味「危険」ですらあるのです。

プログラムはどこまで似ていると著作権侵害になるのか

では実際に、著作権侵害の成否が法律上はどのようにして決まっていくものなのでしょうか。過去の判例・裁判例をもとにみていくことにしましょう。

プログラムの著作権侵害が争われた判例・裁判例

以下に引用する裁判例では、元従業員が転職先で開発したソフトウェアの著作権侵害が争われました。結果としては、著作権侵害が認められました。

上記35個の原告ファイルとそれに対応する上記36個の被告ファイルとを比較すると、(中略)中の黄色のマーカーが塗られた部分(黄色マーカー部分)は、ソースコードの記載が全く同一である。また、上記各号証中の緑色のマーカーが塗られた部分(緑色マーカー部分)は、会社名の置換え、変数名、フォーム名等に違いはあるものの、プログラムとして機能する上で、その名称の違いに意味のないものであり、実質的には同一のソースコードであるといえる。
これらの黄色マーカー部分及び緑色マーカー部分は、上記原告ファイル及び被告ファイルの大半を占めており、その割合は、全体の90％を下らない。

東京地判平成23年5月26日

上記の判決文は、一致割合という客観的の高い数値に基づく判断を行うと同時に、その一致箇所が創作的な箇所にあたるものであるかどうかも吟味することを通じて、著作権法の趣旨を踏まえた判断を行うことを目指したものであると考えられます。

著作権侵害を判断するための法的基準

あるプログラムが他のプログラムとの関係で著作権侵害となるか否かを決する際には、以下のようなポイントを確認していくことになります。

一致(もしくは類似)する箇所の量や割合がどの程度の量に及ぶのか

こうした客観的な数値上の指標でみた場合に、類似度が高ければ高いほど、著作権侵害は認められやすくなるものといえます。一致する行数や文字数といった客観的な比較・検証は過去の裁判においても重視されているものと考えられます。

一致(もしくは類似)する箇所が、どの程度創作的な表現を行いうる箇所であるのか

先述の指標が「形式」であるとするなら、こちらは、著作権法の意義を踏まえた「実質」とも言えるでしょう。すなわち、形式的に一致している箇所において、「それが、その他の表現手法を行いうる箇所か」という観点からも検討がなされていくことになります。たとえば、汎用性の高いライブラリや関数を用いる以外に実装方法が現実的にないような場合であれば、それはありふれた表現手段が個々に採用されただけと見るべきでしょう。

また言い換えるならば、単なるネームスペースの違い(変数や定数、関数の名称等)を変えただけの場合には、実質的にはプログラムの類似度を逓減するものとは言い難いでしょう。プログラマの仕事の創造性は、こうしたネームスペースの用い方で発揮するものではないからです。

さらに付け加えると、バグが生起する箇所がまるごと「盗用」であると考えないと説明がつかないような箇所であるなどといった場合も、著作権侵害を裏付ける要因となりえるものです。

著作権侵害を裁判で争う際の注意点

また以下に、プログラムの著作権侵害を裁判で争う場合にあわせて留意すべき点を整理してみます。

コードが入手できない場合は、立証が困難となってしまうことが多い

先述の裁判例でも示した通り、プログラムの著作権侵害を主張する際には、実際のコードを対比させて検討していくことが必要となります。しかし相手方がソースコードの開示を拒むような場合には、証拠保全そのものが困難になってしまうことが考えられます。そのため、著作権侵害を裁判で争う場合には、被害事実をどのようにまとめ、過去の交渉の経緯をどのように記録し、証拠保全の必要性を主張していくべきかという、いわゆる民事訴訟に関するノウハウも合わせて重要となってくる場合が多いです。

抽象的なアイデアには著作権は及ばない

著作権法10条3項には以下のような規定があります。

3　第一項第九号に掲げる著作物に対するこの法律による保護は、その著作物を作成するために用いるプログラム言語、規約及び解法に及ばない。この場合において、これらの用語の意義は、次の各号に定めるところによる。
一　プログラム言語 プログラムを表現する手段としての文字その他の記号及びその体系をいう。
二　規約 特定のプログラムにおける前号のプログラム言語の用法についての特別の約束をいう。
三　解法 プログラムにおける電子計算機に対する指令の組合せの方法をいう。

著作権法10条3項

要は、物事の処理をどのように進めていくかという「手順」、フォルダ構成など「ものごとの枠組み・課題の整理の仕方」に対しては著作権は及びません。こういったものにまで私的な独占権が及んでしまうとなれば、それこそ著作権法は「文化の発展」に寄与できなくなってしまうでしょう。プログラミング言語そのものやアルゴリズムは、著作物というよりは抽象的なアイデアであり、これらに対しては著作権が及びません。著作権がない以上、そこに対する「著作権侵害」なるものも想定しえないという点もあわせて知っておくと良いでしょう。

まとめ

IT業界における「参考にすること」と「盗用すること」の違いをめぐる議論の難しさには、豊富な視点・多角的な視座が求められる点が挙げられます。そこでは客観的な類似度を見極めるべく両者を比較・検証していく科学的な態度が求められるのはもちろんのこと、著作権法の本質を踏まえた「創作的であるとはどういうことか」といった議論も含まれてきます。

形式と実質、両面を踏まえて論をたてていく姿勢があってこそ、法律もまた、まさにこうした分野・業界に対して「文化の発展」という価値に寄与できるのかもしれません。