\ 開発会社選びで失敗したくない方へ /
システム開発・WEB制作を発注する際の“正しい選び方”を
全8回の無料メルマガでお届けしています。
- よくある失敗例と回避法
- 信頼できる会社を見極めるポイント
- 外注が初めての方も安心
\ 登録はこちら!名前とメールアドレスだけ /
\ 開発会社選びで失敗したくない方へ /
システム開発・WEB制作を発注する際の“正しい選び方”を
全8回の無料メルマガでお届けしています。
\ 登録はこちら!名前とメールアドレスだけ /
システム開発を外部に依頼・受託する際、「著作権」の取り扱いについて注意する必要があります。
この著作権をあいまいにしたまま進めていくと、納品後にトラブルになるケースが少なくありません。
また、発注側からすると、「そもそもシステムやプログラムなどに著作権があるのか」や「コストを負担した側に著作権はないのか」という疑問も浮かぶと思います。
この記事では、システム開発における著作権の基本や契約書で確認すべきポイント、また、著作権がどういったものか、所有権と利用許諾についても併せてわかりやすく解説します。
著作権とは、創作された「著作物(作品)」を創作した者に対して与えられる権利です。
特許のように登録などの手続きは不要で、創作された瞬間から権利が発生します。
美術や文学、写真、映像、講演など様々なものに著作権は発生します。
システム開発における著作権が発生するものは、下記の通りです。
この中でもソースコードの著作権の帰属は、プロジェクトや契約の中で重要なポイントの一つです。
「著作権」と「特許」、どちらも知的財産を守る仕組みですが、実はその性質や使われ方には大きな違いがあります。
それぞれの特徴をわかりやすく紹介します。
著作権は著作者に対して自動的に与えられる権利です。
特許のように出願や登録の必要はなく、創作した瞬間に著作者に権利が発生します。
著作権は「表現」を保護するものであり、技術やアイデアそのものは対象外になります。
特許は特許庁に出願して審査を通過した発明に対して登録される権利です。
登録された特許は一定期間、側線的な利用権が与えられます。
特許は「技術やアイデア」に対して与えられるもので、審査と登録を経て初めて効力が発生します。
システム開発における著作権は、原則として開発者(受注者)に帰属します。
よくある発注側の疑問として
開発費を支払ったこちら側に、著作権などの権利は発生しないのか?
という問いがありますが、結論から言いますと、コストを支払った発注側に著作権は原則としてありません。
例えば、「購入した絵の具や筆で描いた絵画」に対して絵の具や筆のメーカーには著作権が発生しません。
なぜなら、創作した人は「描いた人」であり、道具を提供した人ではないからです。
これはシステム開発にも言えることで、コストを負担したとしても、著作権は「描いた人=開発者」にあるため、委託側には著作権はありません。
しかし、システム開発においては開発者以外に著作権が帰属する場合があり、それが以下の通りです。
このような例が開発者以外に著作権が与えられる場合です。
中でも、最後に紹介した「契約による譲渡」は発注側が特に注意するべきポイントです。
システム開発を外注した際、契約書に著作権に関する記述がないと、後々トラブルに発展してしまいます。
契約書に著作権を盛り込む方法を、目的別・ケース別にあわせてご紹介します。
紹介した方法をそれぞれ組み合わせて運用する企業も多く、目的を明確にしていくことで、費用を抑えたり、効果的なシステムの利用を行うことができます。
もっとも一般的な方法で、著作権をすべて譲渡する方法です。
完全に譲渡すると発注者が開発されたシステムを、自由に改変・再利用・他社への保守依頼が行えるようになるため、トラブルが少なく、資産や事業の知的財産として利用することができます。
受託者は、本契約に基づき作成した一切の成果物に関する著作権(著作権法第27条および第28条に定める権利を含む)を、納品の完了と同時に委託者に譲渡するものとする。
このような記載を行うことで完全な譲渡を行うことができます。
「著作権を譲渡する」と明確に書くこと、著作権法第27条・第28条を含めること、譲渡の対象や譲渡日時などを明確に記載することを、注意して記載する必要があります。
完全譲渡の方法は、トラブル回避や再利用が行えるため、官公庁や大企業、情報管理意識が高い企業やシステムを事業の核と捉える企業に多く見られます。
しかし、この方法は費用が高くなりやすく、契約交渉が難しくなるというデメリットも存在しています。
著作権法第27条と第28条では、著作権の改変、再利用に関する権利が定められています。
第27条は「翻案権」と呼ばれ、マニュアルの翻訳や、PC向けシステムをスマホ用に作り替えるなど、著作物を別の形に改変する権利を意味します。
第28条は、その改変後の著作物をSNSで公開したり、販売したりする「利用の権利」を指します。
これらの権利は、営利・非営利に関わらず無断で行うと著作権侵害になる可能性があり、利用や改変の際には必ず注意が必要です。
先ほど紹介した著作権の完全譲渡に加え、開発者が作った成果物や構造を、他のプロジェクトで再利用することを、明確に禁止する方法です。
発注者が成果物を独占することができます。
この方法では、医療や製薬、金融、法務などの他社への情報漏洩リスクを警戒する企業や、成果物で他社との差別化や、独占を考える企業が行うことが多いです。
しかし、この方法では開発者(受注者側)は改変はもちろん、再利用もできなくなるため、完全譲渡型よりも契約交渉は難しく、費用も高くなる場合が多いです。
出来上がった成果物の一部分のみ著作権の譲渡をする方法です。
開発された成果物である、ソースコードや設計書、マニュアルの中から一部分を切り分けることで、発注者と開発者の要望をそれぞれ柔軟に対応することができます。
完全譲渡型に比べ柔軟性が高く、契約交渉が容易になる一方、著作権の範囲や成果物の整理を明確に分ける必要があり、契約書の設定と管理に時間がかかってしまいます。
しかし、この方法は完全譲渡に比べ費用が抑えやすく、ある程度の情報リテラシーの確保や再利用が可能になることが大きなメリットです。
著作権は開発者に残して、発注者に利用許諾(ライセンス)を与えるという方法です。
他者がその著作物を使うためには原則として著作権者の許可が必要になります。
著作権者が特定の人に利用許諾を与えると、一定の範囲で使用の許可を与えることができます
成果物の著作権はすべて開発者にあるため、改変や再利用、第三者への提供に制限がかかる場合が多いです。
しかし、この契約は非常にコストを抑えやすいため、短期間の導入や、スタートアップ企業によく利用されます。
システム開発において、著作権をめぐるトラブルは少なくありません。
その多くは、契約の際に著作権の所在や取り扱いが、明確に定められていないことが原因です。
このトラブルが起きる詳しい原因と事例、対策について紹介します。
OSSとは著作権が存在する公開されたソフトウェアのことです。(Linux、Firefox、Javaなど)
このソフトは無制限に利用できるわけではなく、ソフトウェアごとに利用・改変・再配布の条件が定められているため、違反すればOSSのソフトウェア会社から法的責任を問われる可能性があります。
発注者が納品されたシステムを改変したところ、開発元から「無断で著作物を改変された」と抗議され、著作権侵害を理由に損害賠償を請求された。
契約の際に「第27条と第28条」を含めた著作権の譲渡契約
改変・再委託・保守を自由に行えるように明確に記載しておく
納品されたシステムにOSSを使用しているのにもかかわらず、発注者がその事実を知らずに利用した。
その後、OSSのライセンス違反が発覚しシステムの停止を受けることに。
納品されたシステムのOSSや第三者ライブラリの確認と、それらの利用条件を確認する
著作権が開発者にあるため、他社への再委託ができずトラブルに発展
契約の際に著作権の取り扱いや再委託についての明確化
開発者が退社しても他社に引き継げる状態の確保を約束
契約が曖昧であったり、要望が通っていないと数年後に重大な問題になるケースがとても多いです。
著作権トラブルを防ぐには、契約の際、著作権の譲渡や、ライセンスなどを明確にしておくことがとても重要です。
著作権は原則として、創作した開発者に帰属し、発注者は契約で譲渡や利用許諾を受けなければ自由に改変・再利用することはできません。
システム開発を外部に発注する際、著作権の所在や取り扱いを明確にしないと、納品後にトラブルが発生することが少なくありません。
企業の目的や情報管理方針に応じて契約形態を選ぶ必要があります。また、OSSや第三者ライブラリの利用においても、各ライセンス条件を遵守することが求められます。
システム開発についてわからないことは、開発歴20年以上のSELECTOにご相談ください。
気になっているけど、まだ動けていない…
そんな方に向けて、全8回の無料メルマガを配信しています。
外注初心者でも安心して使える開発会社選びの考え方と
失敗しないためのチェックポイントをまとめました。
\ 名前とメールアドレスだけ!登録はこちら /