IT訴訟解説：プログラムの著作権を争った判例「DOS版をWindows用に書き換えただけで著作権を主張するとは、ちゃんちゃらおかしいわ！」

●プログラムは著作物なのか

【その他の画像】

　今回はプログラムの著作権について解説する。

　コンピュータのプログラムは、著作物に当たるかどうかの判断が非常に難しい。著作権法では第2条一において、著作物を「思想又は感情を創作的に表現したものであつて、文芸、学術、美術又は音楽の範囲に属するものをいう」と定めており、著作者ではない者が著作者の許諾を得ることなく利用したり、複製したり、翻案したりすることなどを禁じている。そして同じく著作権法第2条十の二において、コンピュータのプログラムも著作物と判断し得ることが規定されている。

　しかしそもそもプログラムとは「思想又は感情を創作的に表現したもの」ではなく、コンピュータに期待通りの動作をさせるための命令の羅列であって、この規定をそのまま当てはめることには無理がある。とはいえプログラムの制作には一般に技術者のさまざまな工夫やアイデアが必要であり、何らかの形で保護しなければ多くの技術者やその所属団体が納得しないことだろう。

　頭に汗をかき、自分だからこそ思い付いたアイデアを他人に何の制約もなく複製され便利に使われたり参照されたりするようではプログラミングなどやってはいられない。自分が一から努力して作り上げたプログラムと、それを他人が勝手に複製して作ったプログラムが、同じ機能や性能を持つからといって同じ価値で取引されることなど到底受け入れられないだろう。

●独自の工夫とアイデアがあれば、とはいうが……

　これまでの裁判ではプログラムについて、「そこに独自の工夫やアイデアがあるかどうか」を見定めて、著作物に当たるかどうかを判断しているケースが複数見られる。

　ある機能を実現する上で、言語の規則やシステムの制約上、誰が書いてもおおむねこのようなプログラムになるであろうというものは著作物とは認められない。しかし、他人が思い付かないであろう工夫で、複雑な処理や使い勝手の良い画面、速度の向上などを実現したのであれば、著作物と認められる可能性はある。これまでの裁判の例を見ると、おおむねそのような判断がなされているようである。

　とはいえ、では何が独自の工夫やアイデアなのかというと、これもまた判断が難しい。恐らく今後、数多くの判決が出される中で徐々に修練していくものなのかもしれない。

　今回はそうした裁判の事例の中では比較的明確にプログラムの著作物に関して言及されているものを見ていきたい。非常に古い技術を巡る裁判ではあるが、争点自体は現代でも有用であるため紹介することとした。

　事件の概要を見ていこう。

---

大阪地方裁判所 平成19年7月26日判決より

ある企業（以下、ユーザー企業）がグラブナビゲーションシステム（水底の土砂などを掘削する船舶のナビケーションなどを行うシステム）の一部をソフトウェア開発企業（以下、開発企業）に依頼し、開発および機能追加を行った。ところがユーザー企業は、開発企業の作成した機能を利用するなどしてプログラムを開発し、別途プログラムを販売するなどした。

開発企業はこれについて自らの作成したプログラムについての著作権侵害に当たるとして訴えたが、ユーザー企業は、このプログラムは著作物に当たらないと反論した。

出典：裁判所Webサイト 事件番号 平成16年（ワ）第11546号

---

●開発者が独創的と思っても、他人から見れば……

　船舶のナビゲーションという特殊な業務を対象とするプログラムを巡る裁判である。開発企業は、MS-DOSに対応したプログラムをWindowsに対応させた。ユーザー企業は「OS更新への対応に創作性はなく、開発企業の作成したプログラムは著作物ではない」との考えの下、これを利用して別の商売に使ったようである。

　開発企業の言い分は、「新しいプログラムはWindowsに対応するために、言語も変えて作成しているし、各種の機能も追加してソースコードの行数も数倍に膨れ上がっている」というものだった。これに対しユーザー企業は「追加された機能のプログラム自体には新規性もなく、開発企業は創作行為を行っていない」と反論している。

　いつものことだが、プログラムの著作性、あるいは創作性の有無を判断するのは非常に難しい。正直、著作権法の考え方からすれば新規に作成したソースの行数や言語の変更はあまり材料にならない気はするが、機能が追加されたとなればそこで開発者がさまざまな検討をし、いろいろなアイデアもあったであろう。

　しかし、そうではあっても、プログラムとはコンピュータに対する命令群である以上、開発者が独自性を出すこと自体が難しいものである。仮に開発者が全く新しく考えたつもりのロジックでも、別の開発者から見れば、どこにでもある平凡な技術と判断されることもある。

　では、裁判所の判断基準はどのようなものであったのか、判決の後半を見てみよう。

---

大阪地方裁判所 平成19年7月26日判決より（つづき）

本件プログラムにおいて、G1XMS-DOS版では（Windowsに対応するために一部機能が使えなくなる。これに対応するために）

（中略）

（新たに）同部分を設けるか、設けるとした場合に同部分をどのようなプログラムとするのか、その場合の関数の使用の有無・内容、プログラムの量などについて、さまざまな選択肢があり、プログラマーの個性を発揮することが可能であるところ、開発者は記憶させるデータのタイプを13分類して、そのタイプを指定することにより、画面からの入出力が共通のルーティンとして使用する（などの）

（中略）

独特の表現をしており、同部分については、開発者の工夫が凝らされていてその個性が認められるから、著作物性を有する。

---

　裁判所は、開発企業の作ったプログラムに著作権を認める判決を出した。

●作り方が十人十色のようなものであれば……

　文量の関係上判決文を大幅に省略したが、その他の部分も踏まえて著作権が認められる基準を整理すると、下記が条件として挙げられている。

1. ある機能を実現するかどうかに選択の余地があること

2. プログラムについてさまざまな選択肢があり、開発者の個性が発揮され得ること

3. 書かれたプログラムに開発者独自の工夫があること

4. （抜粋部にはないが）そもそも開発する機能が、システムの動作上、有用であること

　「実現方法の選択肢があり、開発者の創意工夫があり、他の開発者が行えば別の実現方法になること、そしてプログラムが有用であること」があれば著作物となり得るということになろう。

　この判断は過去のプログラム著作権をめぐる裁判と基本的な考え方は同じである。本裁判はその基準を比較的明確に述べたものであり、今後の参考になると考える。

●それでも著作権の主張は難しい

　このようにプログラムも一定の条件を満たせば著作物となり得るわけだが、これを開発現場で意識することは難しい。私が書く本連載のような文章は、そのほとんどが著作物であると理解されている。音楽や絵画も同じで、何らかの証明などしなくとも周囲はそのように理解するし、制作者自身もそのように考えている。

　しかしコンピュータのプログラムの場合は、ただ書いただけで著作物と認められるわけではない。

　事実、プログラムのほとんどは言語の規則やアルゴリズムの妥当性、効率性などにより似通った書き方になるし、他人の作ったものを流用して書いていることも多く、開発者が著作権を主張するのは難しい。しかし、その中には確かに開発者独自の工夫が含まれているものもあり、そうした部分については著作権を認めないと開発者の権利が阻害され、日本のIT産業にも悪影響を及ぼしかねないし、そこが曖昧だと、本件のような裁判にもなってしまう。

　もちろん、契約で「完成後は著作権を譲渡する」旨を合意すれば、本件のような問題は起きない。開発者は全てを諦め、その分高い対価を受け取ることで納得する。

　しかし、プログラムの中には開発者が権利を留保したいものもあろう。AI（人工知能）などの技術の高度化、複雑化が進展して、プログラミングの選択肢が広まり、新たなアイデアの必要性も高まって、今後は開発者が独自性を発揮する範囲も広がるかもしれない。これを制約するようなことは開発者のモチベーションを落とすし、IT業界にとっても大きな損失になる。

　ただ一方で、開発者がプログラムのある部分にだけ著作権を主張し、複製や改編などを許さないとなれば、システムの保守や更改の生産性を落とす。ある開発者に作ってもらったプログラムやシステムを他の者が一部修正したり、作り直したりするときに、著作権に関わる部分は一から作り直すというのは合理的ではない。

　前述したように著作権譲渡が契約上定められていれば心配ないが、もしかしたら今後は、こうした契約が主流でなくなる可能性もある。開発者の権利と保守性の両立は今後、厄介な問題となってくる可能性が否定できないと思うところである。

●GPLの考え方

　ではどうすればいいのかという答えを私が持っているわけではないが、世界的にかなり広まっているGPL（GNU General Public License）のような考え方を開発に取り入れることも一つの手段ではある。

　開発者は著作権を留保しながら、自ら作ったプログラムの複製や翻案などは許す。その代わりに対象プログラムの著作権は開発者にあることを明記し、これを削除することは許さない、プログラムが無償でも有償でも適用される、というオープンソースソフトウェアの考え方は、開発者のモチベーション、対価、プログラムの保守性いずれも破損しない方法に思える。クローズドな開発契約でこうした文言はあまり見たことがないが、契約の在り方も今後は検討する余地があるのではあるまいか。

●細川義洋

ITプロセスコンサルタント。元・政府CIO補佐官、東京地方裁判所民事調停委員・IT専門委員、東京高等裁判所IT専門委員NECソフト（現NECソリューションイノベータ）にて金融機関の勘定系システム開発など多くのITプロジェクトに携わる。その後、日本アイ・ビー・エムにて、システム開発・運用の品質向上を中心に、多くのITベンダーと発注者企業に対するプロセス改善とプロジェクトマネジメントのコンサルティング業務を担当。独立後は、プロセス改善やIT紛争の防止に向けたコンサルティングを行う一方、ITトラブルが法的紛争となった事件の和解調停や裁判の補助を担当する。これまでかかわったプロジェクトは70以上。調停委員時代、トラブルを裁判に発展させず解決に導いた確率は9割を超える。システム開発に潜む地雷を知り尽くした「トラブル解決請負人」。2016年より政府CIO補佐官に抜てきされ、政府系機関システムのアドバイザー業務に携わった