システム開発の著作権・ソースコードは誰のもの？契約で決めるべきこと
システム開発の著作権とソースコードは誰のものかを解説。著作権が原則として開発会社に帰属する理由、譲渡と利用許諾の違い、契約に入れておくべき項目を発注者向けに紹介します。
お金を払って作ってもらったシステムでも、著作権やソースコードが自動的に発注者のものになるわけではありません。システム開発の著作権は、契約で何も決めなければ原則として開発会社に残ります。この記事では、その理由と、著作権の譲渡と利用許諾の違い、ソースコードの納品を契約に入れる必要性、汎用部品の扱いを、発注者が契約前に確認すべき点としてまとめます。
システム開発の著作権は、原則として開発会社に帰属する
プログラムは著作権法で保護される「著作物」です（著作権法第10条第1項第9号）。著作権は、登録などの手続きをしなくても、作った時点で作った人に発生します（同法第17条第2項）。
開発会社の社員が仕事として書いたプログラムは、契約や勤務規則に別段の定めがない限り、その開発会社が著作者になります（同法第15条第2項）。発注者は代金を払っていても「作った人」ではないため、契約で定めない限り著作権を持ちません。
著作権を持たない場合でも、納品されたプログラムの複製物の所有者は、自分のコンピュータで実行するために必要な限度で複製することは認められています（同法第47条の3）。ただし、他社に改修を頼む、別のサービスに流用する、といった使い方まで自由にできるとは限りません。IPA（情報処理推進機構）のモデル契約書は、著作権を持たない発注者でも法律が認める範囲で保守運用を他社に委託することは可能と整理していますが、どこまでが認められる範囲かは個別に判断が必要です。後で迷わないよう、契約で明確にしておく方が安全です。
著作権の「譲渡」と「利用許諾」の違い
発注者が権利を得る方法は、大きく2つあります。
譲渡にする場合、注意したい点が2つあります。
1つ目は、翻案権など（同法第27条・第28条）の扱いです。譲渡契約でこれらの権利を「特に明記」していないと、譲渡した側に残ったものと推定されます（同法第61条第2項）。翻案権は、プログラムを改変して新しいものを作る権利です。契約書に「著作権法第27条及び第28条の権利を含む」と書かれているか確認しましょう。
2つ目は、著作者人格権です。作った人の人格的な利益を守る権利で、譲渡できません（同法第59条）。そのため実務では、「開発会社は著作者人格権を行使しない」という特約を置くことが一般的です。
ソースコードの納品を契約に入れる必要性
著作権の帰属と、ソースコードを受け取れるかどうかは別の問題です。著作権の譲渡を受けても、実行用のファイルしか納品されなければ、他社に改修を頼むことは現実的に困難です。
契約書の「納入物」の一覧には、次のものを明記しておくことをお勧めします。
- ソースコード一式（リポジトリごと引き渡すのか、どの時点の版か）
- ビルドやデプロイの手順書
- 設計書、データベースの定義書
- サーバーや外部サービスのアカウント、設定情報の引継ぎ方法
IPAの情報システム・モデル取引・契約書（第二版）も、ソースコードや付帯するドキュメントの開示・交付を受けるには、納入物にソースコードを明記するか、エスクロウ（第三者への預託）を活用する方法があると説明しています。将来の開発会社の乗り換えに備える意味でも重要です（開発会社の乗り換えも参考にしてください）。
汎用部品（ライブラリ等）の扱い
システムには、開発会社が以前から持っている共通部品や、外部のライブラリ、オープンソースソフトウェア（OSS）が組み込まれます。これらまで発注者に譲渡することは、通常できません。
モデル契約書は、納入物の著作権について3つの案を示しています。
B案のように発注者に移す範囲を広げるなら、その対価を委託料に反映する形も考えられる、とモデル契約書は説明しています。著作権を発注者に移すかどうかは、価格にも関わる交渉事項です。
C案の「共有」は公平に見えますが、共有の著作権を行使するには共有者の合意が必要になるため、モデル契約書は、その合意をあらかじめ契約で与えておく条項を置いています。共有を選ぶなら、どちらが何をできるかを具体的に書いておくことが大切です。
OSSは、それぞれのライセンス条件に従って使う必要があります。ライセンスによっては、改変したソースコードの公開を求められるものもあります。どのOSSを使っているかの一覧を納品物に含めてもらうと、後の管理が楽になります。
契約前に確認したい項目の一覧
見積や契約書の案を受け取ったら、次の項目が書かれているかを確認してください。書かれていなければ、契約前に質問するのが確実です。
受託開発の現場から
ある受託開発会社が、著作権・ソースコードについて現場で重視している点です。
- ソースを見られない構成は後で身動きが取れなくなる。 別の開発会社が作った標準APIのソースコードを、発注側で見られない状態が問題視された例があります。インフラを移行するにはリバースエンジニアリング（動作から仕組みを解析すること）が必要になるためです。
- 受け取るだけでなく、保守できる形にする。 委託先がAIで書いた数千行規模のスクリプトを、発注企業の社員が保守できないことが課題になった例もあります。ソースコードと一緒に、保守できる設計とドキュメントが必要という考えです。
- 成果物は発注者帰属、汎用テンプレートはライセンス提供。 同社の提案書では、成果物のソースコードは発注者帰属で契約可能とし、開発会社の汎用テンプレートは開発会社が保持してライセンス提供とする形を示しています。コードはGitHubで発注者の資産として保有できることも説明しています。
- RFPに知的財産の項目を立てる。 外食チェーン向けのRFP（提案依頼書）の骨子では、「契約条件・知的財産の取り扱い」を独立した項目にしていました。事前調査の成果物も発注者に帰属させ、他の開発会社への提示を制限しない形をとっています。
まとめ
- プログラムの著作権は、契約で定めなければ原則として開発会社に残る
- 譲渡なら「第27条・第28条の権利を含む」と明記し、著作者人格権の不行使特約を置く
- 著作権とは別に、ソースコードと手順書の納品を「納入物」として契約に書く
- 汎用部品やOSSは譲渡の対象外になるのが通常なので、範囲とライセンスを確認する
本記事は一般的な情報提供を目的としたもので、個別の契約や法的判断については弁護士などの専門家にご相談ください。
権利の扱いも含めて開発会社を比べたいときは、FastProposal の無料AI相談で案件を整理し、費用の目安を確認するところから始められます。