ソースコードの権利は何から決めますか
最初に決めるのは二択です。納品されるソースコードの著作権を譲り受けるのか、使用の許諾を受けるのかです。この選択で契約書の条文が変わります。
どちらが正解かは決まっていません。判断の材料は、将来その仕組みを自社で改修したいかどうかです。
譲渡と許諾のどちらを選ぶか
2つの違いを整理します。
| 項目 | 著作権の譲渡 | 使用の許諾 |
|---|---|---|
| 改修する自由 | 自社の判断で改修できます | 許諾の範囲内に限られます |
| 他社への引き継ぎ | 制約が少なくなります | 許諾の条件によっては難しくなります |
| 費用 | 上がる場合があります | 抑えやすくなります |
| 外注先の再利用 | 外注先は同じコードを使えません | 外注先は他案件にも使えます |
外注先が汎用の部品を持っている場合、全部の譲渡は現実的ではありません。譲渡の対象を新規に書いた部分に限る形もあります。
放っておくと権利はどこにあるか
契約で何も決めない場合、著作権は外注先に残ります。根拠は著作権法の規定です。
著作権法第15条第2項は、プログラムの著作物について定めています。法人等の発意に基づき、その業務に従事する者が職務上作成した場合の規定です。作成時の契約や勤務規則に別段の定めがない限り、その法人等が著作者となります。
出典: 著作権法 (e-Gov法令検索)
つまり、外注先が雇用する技術者が書いたコードの著作権は、まず外注先の法人に生じます。発注者が費用を負担していても、自動的には移りません。
当社の実装経験では、ここを確認せずに数年が過ぎる例があります。別の会社へ改修を頼む段になって、権利の所在が問題になります。契約の時点で決めておけば済む話です。
つまずきやすい点は、見積書や提案書に「納品物一式」とだけ書かれている場合です。何を納品するかは書かれていても、権利がどう動くかは書かれていません。この2つは別の取り決めです。
なお、本記事は条文と公開資料の整理です。個別の契約については、弁護士に確認してください。
契約書にどう書けば権利が移りますか
著作権を譲り受ける場合は、著作権法第27条および第28条の権利を含むと明記します。この特掲がないと、改変にあたる権利が移らないと解される可能性があります。
条文の名前が並ぶと身構えますが、書き方は定型です。理由を知っておけば、外注先との確認も短く済みます。
特掲が必要な理由
根拠は著作権法第61条第2項です。著作権を譲渡する契約が対象になります。第27条または第28条の権利が譲渡の目的として特掲されていない場合の規定です。これらの権利は、譲渡した者に留保されたものと推定されます。
出典: 著作権法 (e-Gov法令検索)
第27条は翻訳権や翻案権などです。第28条は二次的著作物の利用に関する原著作者の権利です。ソフトウェアでいえば、改変して使う場面に関わります。
つまり「著作権を譲渡する」とだけ書いた契約では足りない場合があります。実務では次のように書きます。
- 譲渡の対象を特定します。納品物のうちどの部分かを明記します。
- 「著作権法第27条及び第28条の権利を含む」と特掲します。
- 権利が移る時期を決めます。検収の完了時か、代金の支払い時かを選びます。
- 対象から外れるものを列挙します。外注先の既存資産などです。詳しくは後述します。
つまずきやすい点は3です。代金の支払い時と定めた場合、支払いが済むまで権利は移りません。分割払いのときは、どの時点かを明確にしてください。
著作者人格権の扱い
著作者人格権は、著作者の一身に専属します。譲渡できないとされています。
出典: 著作権情報センター (CRIC)「著作者にはどんな権利がある？」
そのため、著作権を譲り受けても著作者人格権は移りません。実務では、行使しない旨を取り決めるかどうかが論点になります。
取り決めの内容は、案件によって変わります。公開の方法や表示の扱いに関わるためです。外注先が個人の技術者の場合は、とくに丁寧な説明が必要になります。
当社の実装経験では、この条項で止まる交渉があります。理由を説明せずに不行使だけを求めると、警戒されやすいためです。改修や再構築の可能性を伝えると、合意しやすくなります。
既存の部品やオープンソースはどう扱いますか
外注先が持つ既存の部品と、第三者のオープンソースは、譲渡の対象から外れるのが通常です。対象外の範囲を一覧で明示してもらいます。
すべてを譲渡させる形は、現実には成立しにくくなります。外注先は過去の蓄積を使って費用を抑えているためです。
外注先の既存資産の切り分け
契約では、次の3つに分けて考えます。
- 本件のために新しく書いた部分。譲渡の対象にしやすい範囲です。
- 外注先が以前から持っている部品。譲渡ではなく、使用の許諾を受ける形が一般的です。
- 第三者が提供するライブラリやサービス。提供元の条件に従います。
2については、許諾の条件を確認してください。確認する項目は次の3つです。
| 確認する項目 | 内容 |
|---|---|
| 範囲 | 本件のシステムでのみ使えるのか、他の用途でも使えるのか |
| 期間 | 期限があるのか、永続なのか |
| 再委託 | 別の開発会社が改修する際にも使えるのか |
つまずきやすい点は再委託です。将来ほかの会社へ保守を移す可能性があるなら、この点を先に確かめてください。使用の許諾が外注先との取引を前提にしている場合、乗り換えが難しくなります。
オープンソースの条件の確認
オープンソースは、利用の条件がライセンスとして定められています。条件は種類によって異なります。表示が必要なもの、改変した部分の公開が必要なものなどがあります。
発注者として確認するのは次の2点です。
- 使われているオープンソースの一覧を出してもらう。所要時間の目安は、外注先の作業として数日です。
- 自社の使い方が条件に反しないかを確認する。社外に配布する予定がある場合は、とくに確認が必要です。
実装者の視点で補足します。オープンソースは直接指定したものだけではありません。ライブラリが内部で別のライブラリを使っている場合があります。一覧を出すときは、そこまで含めるよう依頼してください。
自社の中だけで使うシステムと、顧客へ配布するシステムでは、条件の重さが変わります。配布の予定がある場合は、設計の段階で伝えておくと手戻りが減ります。
契約書のひな形は何を参照できますか
IPAと経済産業省が公開するモデル取引・契約書を参照できます。通常の開発向けとアジャイル開発向けの版があります。
ゼロから条文を書く必要はありません。公開されたひな形を土台にすれば、論点の抜けを防げます。
モデル契約書の位置づけ
IPAは「情報システム・モデル取引・契約書」を公開しています。ユーザ企業とITベンダの取引の枠組みを示したものです。各工程で双方が負う責任と、契約書のひな形が含まれます。
出典: IPA「情報システム・モデル取引・契約書」
経済産業省も、受託開発と保守運用を対象としたモデル取引・契約書の第一版を公開しています。納品物の著作権をベンダからユーザへ譲渡する場合の考え方が整理されています。挙げられている理由は次のとおりです。
- ユーザが開発の費用を負担していること。
- ベンダが破綻した際に、利用の許諾が終了する事態を避けること。
出典: 経済産業省「情報システム・モデル取引・契約書 (受託開発 (一部企画を含む)、保守運用) 第一版」
この整理は、交渉の場面で使えます。譲渡を求める理由を自社の都合としてではなく、公開された考え方として示せるためです。
アジャイル開発の場合の違い
IPAは、アジャイル開発版のモデル契約書も公開しています。通常の請負契約とは前提が異なります。
| 項目 | 通常の請負を前提とした契約 | アジャイル開発版 |
|---|---|---|
| 開発の進め方 | 要件を固めてから完成を目指します | 短い周期で作り、優先順位を見直します |
| 成果物の考え方 | 完成物を定義して納品します | 周期ごとに動くものを確認します |
| 権利の条文 | 納品の時点を基準に定めやすい | 成果が段階的なため、対象と時期の書き方を工夫します |
アジャイルの形で進める場合も、権利の条文は必要です。周期ごとに生じる成果物のうち、何がいつ譲渡の対象になるかを決めます。
つまずきやすい点は、開発の方式を途中で変えたときです。契約書が最初の方式のままだと、成果物の定義と実態がずれます。方式を変える場合は、権利と検収の条文も見直してください。
アジャイル契約そのものの注意点は、別の記事で扱っています。