共同著作者に無断で改変したので、2800万円請求します：「訴えてやる！」の前に読む IT訴訟徹底解説（138）（2/2 ページ）

かつての愛弟子にアイデアを授け、斜面安定解析プログラムを開発した研究者。だが愛弟子の所属企業は、コードを書いたのは自社従業員となった愛弟子であり、研究者が提供したのは発案のきっかけに過ぎないと反論。プログラムの著作権は誰にあるのか――。

[ITプロセスコンサルタント細川義洋, 編集：鈴木麻紀，＠IT] PC用表示関連情報

LINE

Hatena

前のページへ | 　　　　　　

大阪地方裁判所　令和8年1月15日判決より（続き）

プログラム著作物の保護要件について

プログラムをプログラム著作物として保護するためには、プログラムの具体的記述に作成者の思想又は感情が創作的に表現され、その作成者の個性が表れていること、すなわち、プログラムの具体的記述（一般的にはソースコードがこれに当たる）において、指令の表現自体、その指令の表現の組合せ、その表現順序からなるプログラムの全体に選択の幅があり、それがありふれた表現ではなく、作成者の個性が表れていることが必要である。

本件プログラムの著作者について

本件プログラムについて、被告企業の従業員であるA及びBがその制作に関与し、被告企業の著作の名義の下に公表されたことは争いがなく、上記制作は被告企業の発意に基づくものである（弁論の全趣旨）ことからすれば、本件プログラムの著作者がXであるとは認められない。

　裁判所は著作権は被告企業にあるとし、Aの訴えをしりぞけた。

著作権が保護するのは「表現」であり「アイデア」ではない

　本判決が示す原則は、著作権法の基本中の基本である。著作権が保護するのは「具体的な表現」であり、「アイデア」ではない。これを「アイデア、表現二分論」という。

　プログラムであれば、著作権が保護するのはソースコードという「具体的な記述」である。何を実現するかという「発想」、どんな計算式を使うかという「設計思想」、こういう仕組みにしてほしいという「要件」の指示――これらはアイデアの領域であり、著作権の保護対象ではない。どれだけ独創的な発想であっても、それ自体には著作権は生まれないのである。

　従って、ユーザー企業がどれほど詳細に要件定義し、仕様を細かく指示し、設計の方向性を決めたとしても、ソースコードを書かない限り、そのプログラムの著作者にはなれない。コードを書いたベンダー、あるいはベンダーの従業員が著作者である。

　さらに、従業員が会社の指示の下で作成し、会社名義で公表したプログラムは、会社が著作者となる（著作権法一五条職務著作）。従業員が書いたコードの著作権は、職務として作成した以上、会社に帰属する。ベンダー企業はこの点を社内で明確にしておく必要がある。

ITプロジェクトへの示唆　著作権の正確な理解が認識のずれを防ぐ

　「著作権法が保護するのはアイデアではなく、ソースコード」という考えは、ユーザー企業にとって直感に反することもあるだろう。だが、「深く関与したという事実」と、「著作者であるという法的地位」は、別の話だ。この認識のずれが、プロジェクト終了後に双方の間で思わぬ摩擦を生む場合がある。

　ベンダーがユーザー企業に、成果物の著作権がどこに帰属するかをプロジェクト開始時に説明することは、こうした摩擦を未然に防ぐ上で有効である。義務ではないが、著作権の基本的な仕組みをユーザー企業と共有しておくことは、プロジェクトを円滑に進める上での知恵といえるだろう。

本連載で取り上げたIT訴訟事例を細川氏が分かりやすく解説する動画シリーズ「IT訴訟動画解説」をTech LIVEで公開中です。ぜひ、ご覧ください。

細川義洋

ITプロセスコンサルタント。元・政府CIO補佐官、東京地方裁判所民事調停委員・IT専門委員、東京高等裁判所IT専門委員

NECソフト（現NECソリューションイノベータ）にて金融機関の勘定系システム開発など多くのITプロジェクトに携わる。その後、日本アイ・ビー・エムにて、システム開発・運用の品質向上を中心に、多くのITベンダーと発注者企業に対するプロセス改善とプロジェクトマネジメントのコンサルティング業務を担当。

独立後は、プロセス改善やIT紛争の防止に向けたコンサルティングを行う一方、ITトラブルが法的紛争となった事件の和解調停や裁判の補助を担当する。これまでかかわったプロジェクトは70以上。調停委員時代、トラブルを裁判に発展させず解決に導いた確率は9割を超える。システム開発に潜む地雷を知り尽くした「トラブル解決請負人」。

2016年より政府CIO補佐官に抜てきされ、政府系基幹システムのアドバイザー業務に携わった

個人サイト：CNI IT アドバイザリ