システム開発の著作権について | トラブル回避のための対策を開発ベンダーが解説

システム開発において、「著作権」が発生することをご存じでしょうか？この問題を軽視したままシステム開発を外部企業に依頼すると、深刻な著作権問題に直面することもありえます。

この記事では以下のポイントについて、開発ベンダーならではの視点で、わかりやすく解説します。

• システム開発における著作権とは？
• システム開発の著作権における3つのリスク
• 著作権にまつわるトラブルや裁判事例
• トラブルを防ぐための契約時チェックポイント
• 契約後に著作権問題が発覚した際の対応方法

著作権の基本を押さえ、トラブルを未然に防ぐ体制を整えることで、システム開発をより安心・安全に進めましょう。

「著作権」とは

システム開発における著作権について解説する前に、そもそも「著作権」とは何かについて、簡単に説明します。

「著作権」とは作者が自分が創作した著作物の利用方法を制限・管理できる権利のことです。著作物とは、著作権法第2条第1項第1号において、「思想又は感情を創作的に表現したものであって、文芸、学術、美術又は音楽の範囲に属するもの」と定義されます。音楽や小説、絵画など、幅広い創作物が対象です。

「所有権」と「著作権」の違い

「著作権」とよく混同しがちなのが「所有権」です。

「所有権」とは、民法第206条で保証されている、「その対象の物を自由に使用して収益を得たり、自由に処分できる権利」です。

例えば、レストランのオーナーがとある画家から絵画を購入したとします。所有権は画家からオーナーへ移るので、その絵を自分のレストランに飾ることは問題ありません。しかし、その絵を無断で複製して、レストランで販売することは禁じられています。画家の著作権(この場合は複製権)の侵害となるからです。

このように、著作権と所有権は異なります。誤って著作権を侵害しないために、違いを抑えておきましょう。

システム開発における著作権の原則

著作権の基本を理解したところで、システム開発における著作権について説明します。

著作権法第2条第1項第10号の2によると「コンピュータを動作させるために用いられる命令の組合せ」であるプログラムもまた、著作権の対象です。

そして、その著作権は原則として「著作権は著作者に帰属」します(著作権法第17条第1項)。つまり、外部企業である開発ベンダーがシステムのプログラムを書いた場合、原則、そのシステムの著作権は開発ベンダーに帰属するのです。発注企業が持つのは所有権のみとなります。

所有権の範囲内で、発注企業がそのシステムを利用し、収益を上げることに問題はありません。しかし、そのプログラムを勝手に複製したり、勝手に修正・変更を加えることは、開発ベンダーの著作権を侵害してしまう行為となるのです。

システム開発における著作権の3つのリスク

システム開発における著作権の基本概念を理解したところで、発注企業が著作権を持たなかった場合のリスクを3つ、解説します。

• 改修時の追加費用
• 外部業者へ乗り換えが困難
• 自社での再利用不可

改修時の追加費用

著作権が開発ベンダーにある場合、発注企業は開発ベンダーの許可なく改修を行うことはできません。

例えば、既存の営業管理システムに、ちょっとした改修をしたい場合でも、仮にどれだけ簡単な開発であったとしても開発ベンダーに許可を得るか、あるいは開発ベンダーに改修を依頼することになるのです。

追加改修を依頼する場合は、その分当然追加費用が発生してしまいます。また、コストだけでなく、自社で対応するより時間がかかる可能性が高くなるでしょう。

外部業者へ乗り換えが困難

システム開発では、開発を行った会社とは別の会社に既存システムの改修を依頼することも、珍しくはありません。成果物の質が低い、料金が高い、技術力に不満がある、サポートが不十分だった、など乗り換える理由はさまざまです。

しかし、この場合でも発注企業に著作権がなければなりません。著作権の所在がわからないまま、開発ベンダーとは異なるベンダーが既存システムを改修することは困難です。改修依頼をしても、「著作権の侵害にあたる」と対応を断られてしまう可能性があります。

自社での再利用不可

自社に著作権がない場合は、システムの再利用もできません。システムの再利用とは、既存システムを、そのまま別の目的で複製し、利用することをいいます。

例えば、日本を拠点としている会社が使用しているシステムを、海外の子会社に複製してそのまま利用しようとするという行為は、著作権の複製権侵害に該当します。

また、既存システムの一部の機能だけでも問題となります。既存の顧客管理システムから、ログイン機能やユーザの登録・編集機能だけを抜き出して、従業員の管理システムを作ろうとする場合も、著作権の侵害となるのです。

システム開発の著作権をめぐるトラブル事例や判例3つ

ここまで、システム開発における著作権の考え方やリスクについて解説しました。

ここではトラブルの事例や実際の裁判の判例をご紹介します。

• Case1：開発ベンダーによる囲い込みの現実
• Case2：著作権を持つ開発会社の倒産
• Case3：発注企業の著作権を認めない判例

Case1：開発ベンダーによる囲い込みの現実

発注企業に著作権がない場合、著作権を持っている開発ベンダーにシステム改修を依頼せざるを得ないという状況が生まれます。

開発ベンダーの立場からすれば、「自社で請け負ったシステム開発の改修案件は、基本的には自社で担当したい」というのが本音です。自分たちで作ったシステムですので、ノウハウが既にあります。そのまま請け負うことができれば、システムそのものに対して新たな労力を割いて学びなおす必要がなく、ベンダーとしては利益を上げやすいのです。

このような理由から、あえて著作権を保持したままにしたがる開発ベンダーも存在します。しかし、著作権に縛られた状態で、発注企業が自由に開発ベンダーを選べないような関係性は、ビジネスとして健全なものとは言い難いでしょう。

Case2：著作権を持つ開発会社の倒産

著作権を持ったシステム開発会社が倒産していた場合、一からシステムを構築し直さなければならない可能性もあります。

地方ベンダーの倒産を例にあげましょう。数十年前、地方自治体Aが地元の開発ベンダーBに住民税や水道料金の窓口業務システムを構築してもらったとします。保守もベンダーBに依頼をしました。住民税や水道料金の社会インフラの仕組みは、大きく変化しません。依頼はしていたものの、保守もほとんど必要がない状態で長年利用を続けました。

しかし、大きな法律の変化があった際には対応しなければなりません。まだ記憶に新しいインボイス制度の導入においてシステム改修を迫られた企業や団体は多かったことでしょう。

しかし、いざ改修を依頼しようとしたとき、開発ベンダーBは既に倒産していたのです。そうなると困るのは自治体Aです。著作権もない状態でシステムの保守のノウハウもありません。結局、新しいシステムを作り直す結果となってしまいました。

Case3：発注企業の著作権を認めない判例

著作権問題は、裁判に発展する可能性もあります。実際の判例をご紹介しましょう。

(大阪地裁 平成26年（ワ）第845号 損害賠償請求事件(平成26年6月12日))

この裁判は発注企業Xが、開発業者Yを相手に起こした裁判です。企業XはＹにシステム開発を委託し、そのシステムは問題なく納品されました。Ｙはその後、そのシステムアップデートを担当しましたが、Ｙが廃業することになり企業Ｘに通知します。企業Ｘはソースコードの引き渡しを求めましたが、Ｙは応じず、企業Ｘが損害賠償請求をした、という事例になります。

企業Ｘは委託契約により著作権は企業Ｘに既に移転しており、被告はソースコード引き渡し義務があると主張しました。ソースコードとは、人がプログラミング言語を使って書いたプログラムのことです。また、Ｙがソースコードを引き渡さなかったことによって損害が生じたとして賠償請求をしています。

Ｙの主張はシステム開発においてプログラムは納品しており、ソースコードの著作権は譲渡していないというものです。そして、賠償責任もないという主張をしました。

結果として、裁判所は企業Ｘの請求を棄却しました。つまり、著作権の原則通り、ソースコードの著作権は開発業者Ｙにあり、Ｙの発注企業Ｘへの損害賠償の支払い義務もない、と判断したのです。

事例としてはCase2と同様ですが、この判例があるということ自体が重要です。多くの裁判は過去の判例を元に判断します。新しい法律に違反した場合の裁判が世間に注目される理由は、今後、同様の裁判があった場合の判断材料にされるからです。判例があることで、発注企業が契約後に著作権を主張することがいかに困難かがわかります。

著作権トラブルを防ぐために発注者側ができること

では、こうしたトラブルを避けるために、発注者はどうすればよいのでしょうか。

契約前と契約後に分けてポイントを整理します。

契約前のチェックポイント

著作権トラブルを回避するには、契約前の確認が必要です。

すべて確認し、これらはすべて契約書に明記されたうえで、双方が同意していることを確認しましょう。

なお、以下に登場する契約文は一例であり、そのままの引用・利用は推奨しません。実際の契約書への反映にあたっては、発注企業の責任において、個別の状況やリスクを踏まえてご判断ください。

• 著作権の帰属先
• ソースコード/設計書の納品有無
• 開発後の改修自由度
• 第三者への使用可否
• サードパーティ製ソフトウェアの利用有無

著作権の帰属先

契約書に著作権の帰属先が明示されているかを必ず確認しましょう。

そもそも準委任契約の場合、発注企業はシステムを開発する作業を依頼するため、プログラムの著作権は、発注企業が持つ場合が多いです。また、請負契約の場合でも、契約書に明記されていれば発注企業が著作権を持つことも可能です。ただし、請負契約で著作権について明記されていない場合は、著作権は原則開発ベンダーのものになります。

契約書に発注側に著作権を渡すことが書かれていることを、必ず確認してください。

準委任契約の詳しい解説は以下よりご確認ください。
＞＞システム開発における準委任契約とは？請負契約との違いなども徹底解説

契約書の例文はこちらです。

第○条(著作権の帰属)
本契約に基づき開発された一切の成果物(ソースコード、プログラム、設計書、ドキュメント等を含むがこれに限られない)に関する著作権(著作権法第27条及び第28条の権利を含む)は、甲(発注者)に帰属するものとする。

ソースコード/設計書の納品有無

ソースコードとは、人がプログラミング言語を使って書いたプログラムのことです。パソコンなどの機械はソースコードをそのまま読み込むことはできません。人間が書いたソースコードをパソコンが読める言語に翻訳する処理が必要です。このような翻訳処理を行い、最終的には「バイナリ」と呼ばれるパソコンで実行可能な状態にします(厳密には様々ありますが、ここでは割愛します)。「システムを納品すること」とは、この「バイナリ」を納品することだと理解してください。バイナリは、人間が読むことはできません。また、バイナリの上から、新たにソースコードを追加したり改修したりすることもできません。それは英語の上から日本語を書くようなものです。

つまり、著作権以前の問題として、ソースコードが手元にないということは、所有者だけではシステムに手をつけることすらできない、ということになります。

著作権の帰属先を確認するのと併せて、ソースコードや設計書などが納品物として契約書に明記されていることを、必ず確認しましょう。

具体的にはこのような文章があるとよいでしょう。

第○条(成果物の納品)
乙(開発会社)は、成果物として完成したプログラムの実行ファイルに加え、関連するソースコード、設計書、マニュアルその他のドキュメントを甲に納品するものとする。納品物の媒体、形式及び時期は別途協議の上、甲乙双方が合意した方法による。

開発後の改修自由度

著作権が発注企業に存在しない場合でも、所有者の再利用・改変の許可について契約書に明文化されているのであれば、その範囲で変更・改修することが可能です。著作権を丸ごと譲渡してもらえない場合には、限定した形で提案してみるのも有効な対策となります。しかし、発注企業にとって最も自由度が高いのは、「著作権譲渡＋ソースコード納品」です。著作権譲渡に否定的なベンダーを選定するのは、できるだけ避けた方がよいでしょう。

こちらも契約分の例を紹介します。

第○条(成果物の利用および改変)
甲は、本契約に基づき納品された成果物について、自己の業務目的の範囲内で、複製、改変、翻案、公衆送信、第三者への開示・提供等の利用を自由に行うことができる。乙は、これに対して異議を述べないものとする。

第三者への使用可否

契約に直接関与しない第三者のシステムの使用可否も予め協議しましょう。たとえば、発注企業の同じグループ内の会社、フランチャイズ店舗でのシステムの利用です。著作権が譲渡されていない場合は、原則として著作権の侵害に該当します。契約書の内容によっては許容される場合もあるので、どのような契約を結ぶか、事前に必ずチェックしましょう。

＜利用可否パターンまとめ＞

	著作権 譲渡あり	譲渡なし 許諾あり	譲渡なし 許諾なし
自社内の再利用	◯	◯	×
グループ会社での利用	◯	△(契約による)	×
フランチャイズ店での利用	◯	△(契約による)	×

契約文の一例です。

第○条(第三者への使用許諾)
甲は、本契約に基づき納品された成果物を、業務遂行の目的で必要と認める範囲において、第三者(協力会社、保守業者等を含む)に使用させることができるものとする。

サードパーティ製ソフトウェアの利用有無

システム開発を開発ベンダーに依頼した場合でも、すべてのシステムを一から作るわけではありません。具体的な例として、Googleとはまったく関係がないサイトにGoogleアカウントでログインできた、という経験はないでしょうか？これはサイト側が、Googleのログインの仕組みを利用しているのです。こういった第三者が作った仕組みをサードパーティ製の仕組み(=ソフトウェア)と呼びます。

サードパーティ製のソフトウェアの著作権は、そのソフトウェアを作った団体や人物にあります。いくら、開発ベンダーに著作権を譲渡してもらっても、サードパーティ製のソフトウェアを勝手に改修することは、そのソフトウェアを作った団体や人物の著作権を侵害してしまうのです。

これは、サードパーティ製のソフトウェアを使うべきではない、という意味ではありません。世の中には非常に優秀なソフトウェアが多数存在しています。そういったソフトウェアにはライセンスを購入するなどの使用条件が必ずあるのです。それらの条件を理解し著作権に則ったうえで、上手に使用していくことが重要となります。

納品後にトラブルが発覚した場合の対処法

納品後にトラブルが発覚した場合でも、全く対象方法がないわけではありません。慌てずに、以下の対策を実施、検討しましょう。いずれの場合も、やりとりを記録しておくことが大切です。

• 契約書を確認する
• 開発ベンダーと交渉して著作権の譲渡や使用許諾を得る
• 第三者(IT専門、著作権に強い弁護士)に相談する

契約書を確認する

まずは、現状の契約状態を確認しましょう。契約書に著作権にまつわる内容が明記されていない場合、著作権の原則に則り「著作権は創作した者（＝開発者）に帰属する」とされます。しかし、以下のような状況があれば、発注企業が有利になる可能性もあります。

• システムの企画・設計を発注企業が主導し、開発ベンダーは指示通りに作業しただけ
• 納品された成果物が発注企業の業務に密接に関係しており、汎用性がない
• 発注時のメールや議事録などに「著作権は発注企業に帰属する」旨の記述がある

このような場合、実質的に著作権が譲渡されていると認められることもあります。著作権で問題が発生した場合、まずは契約書をしっかりと確認し、当時の記録を辿るようにしましょう。

開発ベンダーと交渉して著作権の譲渡や使用許諾を得る

改めて、開発ベンダーと交渉し、著作権の譲渡や使用許諾について協議するのも手です。新たに著作権譲渡契約や、著作権許諾契約を結び直せば、発注企業が著作権を得たり、許可された範囲で改修や再利用が許されます。

しかし、多くの場合で譲渡や使用許諾を得るための追加費用を求められます。あまりに高額な場合は、著作権を諦めて一からシステムを作り直すことや、次に紹介する第三者への相談も検討してください。

第三者(IT専門、著作権に強い弁護士)に相談する

どうにもならないときは、弁護士に相談し、法的処置の検討をしなければならない場合も考えられます。しかし、契約書に明記がない限り、システムの著作権は開発ベンダーが持つのが原則です。証拠が揃えられない限り、著作権を発注企業が主張するのは難しいのが現実です。

また、裁判を起こすことは企業にとってあまり望ましい結果とはいえないでしょう。裁判の手間や費用を考えれば、既存システムを諦め、別のベンダーに新システムを依頼するという判断もしなければなりません。ここまでくると、もはや経営判断が必要です。担当者の独断で進めてはいけません。この手段は、最終手段として考えておきましょう。

こんなことにならないためにも、やはり、契約前の確認が最も重要なのです。

システム開発の著作権トラブル回避は契約前に

システム開発における著作権の取り扱いは契約時点で明確にしておくことが非常に重要です。改修や再利用、第三者利用といった運用の自由度は、著作権の所在によって大きく左右されます。

しかも、著作権をめぐるトラブルは開発が終わったあとに発覚することが多く、コストも時間もかかる上、最悪の場合はシステムの全面再構築に追い込まれるリスクすらあります。

システム開発を外部委託する場合には、著作権についてしっかりと確認した上で双方の同意の元、契約を結びましょう。

そして、著作権に基づいた自由度の高いシステム運用を行い、自社の業務をより効率化させることを目指してください。

さいごに

株式会社フレシットでは、システムの著作権はお客さまに譲渡する契約を締結しています。著作権をお客さまに譲渡することで、健全なビジネス関係を築けると考えているからです。これは、お客さまとの健全で持続可能な関係を何よりも大切にしているからです。

著作権に関する不安を抱えたまま開発を進めたくないとお考えの方は、ぜひ一度、フレシット株式会社にご相談ください。ご相談は無料で承っております。安心して、未来につながるシステム開発を始めましょう。