IT・ベンチャーの企業法務

プログラムのソースコードは著作権上誰のものか

IT・ベンチャーの企業法務

プログラムのソースコードは著作権上誰のものか

プログラマ・エンジニアが記述するソースコード・プログラムは、著作権法上、「著作物」に該当するものです。したがって、その著作権者が誰であるのかという問題は、システム開発という文脈にも当然及んでくることがあります。本記事では、システム開発との関連で、著作権法上の権利者の所在をめぐって争いになりやすいポイントと、それらに対する解決策について解説していきます。

そもそも著作権法とは

そもそも著作権法がなんのためにある法分野かということになれば、以下に引用する第一条の内容が非常にわかりやすいでしょう。すなわち、権利者個人の権利と、社会全体の利益といった二つの価値のバランスを維持し、「文化の発展」という価値に寄与することを目指した領域だということができます。

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

そして、プログラム・ソースコードについても、著作権法の適用対象であることもまた、条文上にはっきりと明記されています(下線部は筆者が引いたものです)。

第10条1項
この法律にいう著作物を例示すると、おおむね次のとおりである。一 小説、脚本、論文、講演その他の言語の著作物
二 音楽の著作物
三 舞踊又は無言劇の著作物
四 絵画、版画、彫刻その他の美術の著作物
五 建築の著作物
六 地図又は学術的な性質を有する図面、図表、模型その他の図形の著作物
七 映画の著作物
八 写真の著作物
九 プログラムの著作物

まとめると、プログラマが書いてきたプログラム・ソースコードも、法律上列記とした「著作物」であり、そこには権利者が存在してしかるべきであるということです。

システム開発では、どんな著作権問題が起こりやすいか

システム開発における著作権絡みの問題について説明していきます。

システム開発という文脈で、著作権絡みの問題が起きる場合に、ありがちなものは以下の2パターンに大別されます。

1.そもそも誰が著作権者として、権利をもつことになるのか
→原始的に権利の帰属する人、著作権譲渡のタイミングなどに関する問題
2.著作権者にどういった権利が認められるのか(言い換えると、著作権者でない人にはなにが認められていないのか)
→複製や翻案などに伴う「著作権侵害」の成否の問題

つまり、1が「権利の有無にかかわる争い」であり、2が「権利があることを前提とした(あるいは、ないことを前提とした)うえでの争い」であると整理できます。

まず1について整理しておくと、システム開発では、仕事を受けるベンダー側も多数の作業者が分担しながらプロジェクトを進めていく場合が多いため、権利の帰属主体は曖昧になりがちで、ときにややこしい揉め事にも発展します。加えて、ベンダーからユーザーに成果物が引き渡される際にも、その権利の譲渡が認められるかなどをめぐって、争いが起きることがあります。

次に、2については、他人の作った”よく似た”コードが「参考にしただけ」なのか「パクリ」なのかといった問題がこれにあたります。こちらについては、別記事にて詳細に解説を行っています。

本記事ではこうした分野の全体像を踏まえて、主に1の点についての整理を行っていきます。

権利の帰属を争う際の基礎知識

著作権は「作った人」への帰属が原則

まずは、法律上の著作権が誰が帰属するかについて、順を追って整理していくことにしましょう。プログラム・ソースコードの場合にも、その他の創作物と同じように、創作者に原始的に(つまり一番最初に)権利が帰属することになるのが原則です。しかし、以下に引用する職務著作に該当する場合には事情は異なり、製作者ではなく、その雇い主に権利が帰属します。システム開発が、大抵の場合、企業主導で進められるプロジェクトとなるのが通例であることからすると、むしろこちらを原則として理解したほうがわかりやすいかもしれません。

第15条2項
法人等の発意に基づきその法人等の業務に従事する者が職務上作成するプログラムの著作物の著作者は、その作成の時における契約、勤務規則その他に別段の定めがない限り、その法人等とする

つまりは、ベンダーの従業員として開発業務にあたってきたプログラムであれば、その著作権者は原始的にもベンダーとなるということです。

開発の委託は著作権の移転を意味しない

もっとも、著作権も、その他の私法上の権利などと同様に、移転したり譲渡したりすることが想定される権利です。この点に関連して注意を要するのは、報酬を払って開発業務を委託することと、著作権の移転は話として別問題であるということです。有償で開発を委託していることから、納入とともにプログラムの著作権そのものも移転すると誤解されるケースも時折見受けられますが、あくまで著作権法上の原則は、「著作した人に権利が帰属する」というものです。「著作にかかる費用を負担した人に権利が帰属する」というものではありません。したがって、発注者であるユーザーが権利まで取得しておきたいのであれば、事前にその旨も取り決めをしておくことが必要となります。

契約書がある場合とない場合でも話は異なる

なお上述の点について、実務的にもう少し詳しい話をすると、

  • 契約書はあるが著作権の移転については取り決めがない場合
  • 契約書そのものが存在せず、著作権の移転についても勿論特に取り決めがない場合

でも話が異なってきます。

もし契約書があるにもかかわらず、著作権を移転させる旨の取り決めについて記載がないのであれば、著作権の移転はないものと判断される傾向にあります。一方もし契約書そのものが作成されていないような場合であれば、それまでの両当事者のやりとりの経緯を踏まえて、個別に判断されることになります。

モニュメントのデザインに関する裁判例(著作権移転肯定)

なお、こうした点については、システム開発と異なる分野ではあるものの、以下に引用する東京高裁の判例が参考になります。以下の事案は、駅に設置するモニュメントのデザインをめぐり、著作権の譲渡を認めるべきか否かが争われたものです。

本件モニュメントは,岐阜駅南口に設置することが当初から予定されており,それ以外の用途が考えられないものであったことをも考慮すれば,控訴人は,本件モニュメント製作に当たり,被控訴人会社との間で,その提供した図面等に描いたモニュメントのデザイン(本件著作物に当たるもの)について,これが美術の著作物に当たり,著作権により保護されるとしても,被控訴人会社に対し,その著作権を譲渡すること(中略)を,少なくとも黙示的には合意した上で,上記モニュメントに関するデザインを提案し,その対価として,被控訴人会社から,控訴人が要求したとおりの金額でその報酬を得た,と認めるのが相当である。

東京高判平成16年5月13日

当該判決は、著作権譲渡を明確に定める契約書がないにも関わらず、「黙示の合意」を認定し、著作権譲渡があったと認定しています。

出版社のソフトウェアに関する裁判例(著作権移転否定例)

ただ、これに対し、出版社とシステム開発を業とする者との間での紛争である大阪地判平成26年6月12日は、著作権の移転を否定しています。以下のような事案です。

まず、原告である出版社は、被告に対して、出版社が出版する参考書籍をベースにしたテストを自動的に作成するソフトウェアの開発を委託し、その後も継続的にバージョンアップの委託を、バージョンアップの都度見積を取得する形で委託していました。被告は常に成果物をバイナリの状態で納品しており、ソースコードは一度も引き渡されていませんでした。その後、原告は被告に対し、ソースコードの提供が可能かどうかの問い合わせを行ったりしていたのですが、被告はこれに対し、ソースコードの著作権は被告側にあり、ソースコードを提供する理由が無いとして、提供を拒みました。これに対して原告が、原告側に著作権があるにも関わらず被告がソースコードの引き渡しをせず、そのせいで原告が損害を蒙ったとして、被告に対して損害賠償請求を行ったのです。

この事案で、大阪地裁は、以下のような判断を行っています。

(1)本件委託契約の履行に伴う著作権移転の合意の不存在
原告の主張は,本件委託契約に基づき,本件ソフトウェア及び本件ソースコードの著作権の譲渡が合意され,これに伴い,ソースコードの引渡義務も発生するというものである。
(中略)被告が,本件ソースコードを制作したものであり,本件ソースコードの著作権は原始的に被告に帰属していると認めることができる。
その一方で,(中略)見積書等,原告と被告との間で取り交わされた書面において,本件ソフトウェアや本件ソースコードの著作権の移転について定めたものは何等存在しない。
(中略)被告は,原告に対し,本件ソースコードの開示や引渡しをしたことはなく,原告から本件ソースコードの引渡しを求められたが,これに応じていない。
また,原告にしても,平成23年11月に至るまで,被告に対し,本件ソースコードの提供を求めたことがなかっただけでなく,(中略)原告担当者は,被告に,本件ソースコードの提供ができるかどうか問い合わせているのであり,原告担当者も,上記提供が契約上の義務でなかったと認識していたといえる。
以上によると,被告が,原告に対し,本件ソースコードの著作権を譲渡したり,その引渡しをしたりすることを合意したと認めることはできず,むしろ,そのような合意はなかったと認めるのが相当である。
(中略)
(3)継続的契約関係の下における損害発生防止(減少)義務
(中略)
被告は,本件ソフトウェアが最新のオペレーションシステムに対応していないことを言明しており,永続的なアップデートの約束がされたことと相容れない状況となっている。
すなわち,本件委託契約は,事実上継続して取引があったにすぎず,継続的契約関係とも認められない(保守契約が結ばれたことさえ,これを認めるに足りない。)

大阪地判平成26年6月12日

この事案のポイントは、

  • 見積書等の書面は交わされていたが、その中で著作権譲渡の定めがない(言い換えれば、書面自体が存在しない事案ではなく、書面は存在したが、その中でソースコードの著作権の話が出てこない)
  • 開発は、バージョンアップごとに都度見積取得から行われていた
  • ソースコードの開示や引き渡しは、紛争発生直前まで求められていなかった

という点だと思われます。著作権移転それ自体に関わる判断では無く、付随的な判断ではありますが、「継続的契約関係がない」と判示されている点は、上記2に関わるものでしょう。この判決は、

  • 発注側と受注側に継続的な関係が無い(バージョンアップの委託が行われること、それが受託されることについて特に予定が無く、結果として何度もバージョンアップの委託・受託が行われただけ)
  • 「契約書」ではないが見積書等は交わされており、その中で著作権譲渡の話が出てこなかった
  • 現にソースコードの開示や引き渡しも行われていなかった

という事案において、著作権譲渡を否定したものといえます。

著作権の移転はどのように判断されるのか

なかなか「明確なルールがある」とは言い難い話なのですが、あえて整理するとすれば、

契約書等の書面があるのに著作権の移転について特に取り決めがない
→著作権は作った人に帰属するのが原則である以上、あえて契約書に著作権を移転させる旨を明記しないなら、それは原則どおり著作権を移転しない旨の契約が結ばれたもの扱われるケースが多い。
契約書等の書面そのものがなく、著作権の移転の話を含めて、全般的に取り決めがない
→当事者の意思がどのようなものであったと考えるべきか、事案の中身に即して合理的に判断されるケースが多い。その「合理的な判断」の中では、継続的関係の有無・ソースコード開示や提供の有無など、周辺事情も考慮される。

と理解しましょう。

著作権の存否をめぐる主要論点

以上の内容を踏まえて、著作権の存否をめぐる争のパターンを整理してみましょう。非常に大雑把な類型としては、以下の二種類のパターンがあることがわかります。

1.原始的な権利の帰属が争われる場合
→会社の経営者と従業員の間で権利者が争われるような場合など
2.著作権の移転の成否が争われる場合
→ユーザーとベンダーの間で権利者が争われるような場合など

です。1の場合の争いでは、「誰がソースコードを記述したのか」という事実認定の部分が問題になることが多いものですが、2の場合には、「当事者間で、移転することについての合意があったのかどうか」という法的な評価の部分が問題になることが多いという違いもあります。

著作権者を明確にするための手段とは

多数の人達が関わるシステムプログラムにおいて、作成者の特定を明確にすることが必要です。

では、上記の1、2それぞれの場合について争いが起きた場合に、その権利の所在はどのようにしていくべきものなのでしょうか。以下に順を追って整理していきます。

まず対象となっているプログラムの開発者の特定する

ひとつのITシステムは通常、多数のプログラムの集積で成り立つものであり、多数の人員で分担しながら作り上げていくものです。したがって、争いとなっているプログラムの作成者が誰であるのかを調査し、特定することが必要となります。この場合には、ベンダー側の作業スケジュールなどに記された担当者の欄に誰の名前が記されているのかといったことや、ソースコードに記されたコメント欄の作成者情報などが有力な手がかりとなることが考えられます。

次に開発者と会社の関係を整理する

先述の通り、職務著作が成立するのであれば、コードを書いた人ではなく、その人の使用者(通常はベンダーである企業)に原始的な権利が帰属するのが原則です。職務著作については、開発者と、開発者が所属する企業との間に雇用関係があり、その指揮監督のもとで開発されているような場合には比較的容易に認められる傾向にあります。しかし反対に、私的な人間関係に基づく「お手伝い」のようなものであるような場合を想定するとすれば、職務著作の成立の存否が争いとなる可能性もあります。

さらに、著作権譲渡の合意の有無を検討する

ユーザーがベンダーから権利を譲り受けたと主張するような場合には、そうした合意があるという点について、それを主張するユーザー側が立証責任を負うことになります。またさらに、著作権を委託者に譲渡するのかしないのか、受託者が著作権を保持しつづけるのか否かというのは、当事者間で自由に取り決めが可能な事項でもあります。したがって、こうした点での争いを事前に回避するためには、システム開発を委託する段階であらかじめ、著作権の帰属や譲渡、ベンダーからの利用許諾の範囲などについても取り決めを行っておくことが好ましいと言えるでしょう。なお、経産省モデル契約と呼ばれる、官庁が公開するシステム開発の契約の雛形には、下記のような規定を置くことが推奨されています。

第 45 条 納入物に関する著作権(著作権法第 27 条及び第 28 条の権利を含む。)は、甲(ユーザー)又 は第三者が従前から保有していた著作物の著作権を除き、乙(ベンダー)に帰属するものとする。

上記のように、経産省が推奨するやり方としては、ソフトウェアの再利用性を向上を促進させるという狙いもあってか、汎用性の高いプログラムの著作権をベンダー側に持たせることを意図した規定が置かれています。

まとめ

著作権の問題というと、キャラクターやロゴのデザインなどの剽窃問題を真っ先に連想するという人が多いのではないでしょうか。たしかに一人もしくは少人数のクリエイターが、愛着をもってデザインを手がけてきたプロダクトが剽窃などにあえば、心情的にも大きな対立に発展することは想像に難くありません。

一方、大人数で作り上げるシステム開発なるものも、著作権問題と無縁でないことは本記事で指摘した通りです。大人数でプロダクトを作り上げるシステム開発プロジェクトである場合、技術者一人一人が当該システムに「愛着」を持つような場合は、たしかにそう多くはないかもしれません。しかしその分、著作権をめぐる取り決めを事前に十分に行っておくことは、全体を統括する経営者・役職者サイドの重要な役割なのだという認識を持つことは大切であるともいえるかもしれません。

モノリス法律事務所

モノリス法律事務所

モノリス法律事務所は、IT・インターネット・ビジネスに強みを持つ、東京・大手町の法律事務所です。

シェアする

トップへ戻る