「ソースコードの著作権」は誰のもの？納品トラブルを防ぐ知財の知識
「納品されたソースコード、自由に使えると思っていたのに…」
「開発費を払ったのだから、ソースコードは自分のものでしょ？」
「契約書に『著作権は発注者に帰属』って書いてあるから大丈夫」
「納品後に別の会社にメンテナンスを頼んだら、元の開発会社から『勝手に使うな』と言われた」
システム開発を外注した経験のある起業家やスタートアップ創業者なら、こうした疑問や経験を持ったことがあるかもしれません。
実は、ソースコードの著作権問題は、開発外注におけるトラブルの代表的な原因の一つです。
- 納品後のシステム改修を別会社に頼もうとしたら、元の開発会社から著作権侵害を指摘された
- 「ソースコードは渡せない」と言われ、システムの改修ができなくなった
- 開発会社が倒産し、ソースコードの権利関係が不明になった
- 類似サービスを競合他社が立ち上げ、自社のコードが流用されているように見える
このようなトラブルが後を絶たない背景には、「お金を払った＝所有権を得た」という誤解と、著作権法の仕組みへの理解不足があります。
本記事では、非エンジニアの起業家やスタートアップ創業者向けに、ソースコードの著作権に関する基礎知識と、納品トラブルを防ぐための具体的なポイントを解説します。
なぜソースコードの著作権トラブルは起きるのか
「開発費を支払ったのだから、成果物は自分のもの」
この感覚は、日常生活の「買い物」に照らせば自然なものです。家具を買えばその家具は自分のもの。車を買えば自分の車。
しかし、ソフトウェア開発における「成果物」と「著作権」は、全く別のものです。
著作権法では、著作物（ソースコードを含む）の権利は、原則として「創作した人」に帰属すると定められています。つまり、何も取り決めがなければ、開発会社やエンジニアが著作権を持つことになります。
これを知らずに契約を結ぶと、後から「こんなはずじゃなかった」という事態に陥ります。
私たちは「技術がわからないことで挑戦を諦める非エンジニア起業家をゼロにする」というビジョンを持っています。だからこそ、法律や契約といった技術以外の知識についても、正しく理解していただきたいと考えています。
ソースコードの著作権問題は、知識があれば防げるトラブルです。以下で詳しく解説していきます。
ソースコードの著作権、基本の仕組みを理解する
ソースコードの著作権の基本
まず、ソースコードの著作権に関する基本的な仕組みを押さえておきましょう。
著作権は「創作した瞬間」に発生する
著作権は、著作物が創作された時点で自動的に発生します。特許のように出願・登録の手続きは必要ありません。
つまり、開発会社やエンジニアがコードを書いた瞬間、その人（または会社）に著作権が発生します。発注者が開発費を支払っているかどうかは、著作権の発生に関係ありません。
著作権には2つの権利がある
著作権は大きく分けて「著作財産権」と「著作者人格権」の2つで構成されています。
著作財産権（譲渡可能）
- 複製権：コードをコピーする権利
- 翻案権：コードを改変・修正する権利
- 公衆送信権：コードを配信する権利
- など
著作者人格権（譲渡不可）
- 公表権：公表するかどうかを決める権利
- 氏名表示権：著作者名を表示するかどうかを決める権利
- 同一性保持権：無断で改変されない権利
重要なポイントは、著作者人格権は譲渡できないということです。契約書に「著作権は発注者に帰属する」と書いても、著作者人格権は開発者に残ります。
「職務著作」という例外ルール
開発会社の従業員がソースコードを書いた場合、一定の条件を満たせば、著作権は会社に帰属します（職務著作）。
しかし、開発会社から発注者に著作権が自動的に移転するわけではありません。発注者が著作権を取得するには、契約で明示的に取り決める必要があります。
契約がなければ著作権は開発者のもの
繰り返しになりますが、契約で明示的に定めない限り、ソースコードの著作権は開発者（開発会社）に帰属します。
「開発費を払ったのだから当然」という認識は、法律上は通用しません。
実際にあった著作権トラブル事例
ここからは、ソースコードの著作権をめぐる実際のトラブル事例を紹介します。
事例1：システム改修を依頼したら「著作権侵害」と言われた
背景
ECサイトを運営するA社は、初期開発を依頼した開発会社B社との契約が終了後、別の開発会社C社にシステムの改修を依頼しました。
何が起きたか
C社が改修作業を進めていたところ、B社から「著作権侵害である」という警告書が届きました。
A社はB社に開発費を支払っていましたが、**契約書には著作権の帰属についての条項がありませんでした。**そのため、著作権はB社に残ったままだったのです。
結果
A社は、B社に追加で著作権譲渡の対価を支払うか、システムをゼロから作り直すかの選択を迫られました。最終的に数百万円の追加費用が発生しました。
事例2：「ソースコードは渡せない」と言われた
背景
SaaSスタートアップのD社は、MVP（最小限のプロダクト）の開発を個人のフリーランスエンジニアE氏に依頼しました。開発は順調に進み、サービスをリリース。
何が起きたか
サービスが成長し、大幅な機能追加が必要になった段階で、E氏との契約を終了し、別の開発チームに引き継ぐことに。しかし、E氏に「ソースコードを渡してほしい」と伝えたところ、「著作権は自分にあるので、ソースコードは渡せない」と拒否されました。
契約書を確認すると、「成果物の納品」は定められていましたが、「著作権の譲渡」や「ソースコードの引き渡し」については明記されていませんでした。
結果
D社は、E氏と長期間の交渉を行い、最終的に追加の費用を支払ってソースコードを取得することになりました。サービスの成長が半年以上遅れる結果となりました。
事例3：開発会社が倒産、ソースコードの権利が宙に浮いた
背景
業務システムを開発会社F社に発注していたG社。システムは無事に納品され、運用も順調でした。
何が起きたか
数年後、F社が倒産。システムの改修が必要になった際に、ソースコードの著作権が誰に帰属するのか不明な状態になってしまいました。
契約書はあったものの、著作権の譲渡について曖昧な記載しかなく、F社の資産（著作権を含む）は破産管財人の管理下に。
結果
G社は、破産管財人との交渉に多大な時間とコストを費やし、結局システムを作り直すことを選択しました。
事例4：競合に自社のコードが流用されているように見える
背景
アプリ開発を依頼したH社。開発会社I社との契約では、著作権の帰属について「協議の上定める」という曖昧な記載でした。
何が起きたか
1年後、競合他社がよく似たアプリをリリース。調べてみると、その競合もI社に開発を依頼していたことが判明。UI/UXやコードの構造が酷似しており、自社アプリのコードが流用されたのではないかという疑惑が浮上。
しかし、著作権の帰属が曖昧だったため、I社に対して「流用するな」と明確に言える立場にありませんでした。
結果
法的措置を検討するも、証拠の確保や訴訟コストを考えると現実的ではなく、泣き寝入りする形に。
著作権トラブルを防ぐための5つのポイント
著作権トラブルを防ぐポイント
失敗事例を踏まえ、ソースコードの著作権トラブルを防ぐための具体的なポイントを紹介します。
ポイント1：契約書に「著作権の帰属」を明記する
最も重要なのは、契約書で著作権の帰属を明確に定めることです。
契約書に含めるべき条項
- 「本契約に基づき作成された成果物の著作権（著作権法第27条および第28条の権利を含む）は、検収完了をもって発注者に帰属する」
- 「受注者は、本成果物に関する著作者人格権を行使しないものとする」
特に重要なのは、著作権法第27条（翻案権）と第28条（二次的著作物の利用権）を明記することです。これらは、契約書に「すべての著作権を譲渡する」と書いても、特掲しなければ譲渡されないと解釈される可能性があります。
また、著作者人格権の不行使特約も忘れずに入れましょう。
ポイント2：「成果物の定義」を具体的にする
「成果物の著作権は発注者に帰属する」と書いても、「成果物」の定義が曖昧だとトラブルの原因になります。
明確にすべき点
- ソースコード一式（どのリポジトリ、どのブランチまで含むか）
- 設計書、仕様書、ドキュメント類
- データベースの構造定義
- テストコード
- 開発環境の設定ファイル
- 使用したライブラリ・フレームワークのライセンス一覧
「成果物」として何が含まれるのか、具体的にリストアップしておくことが重要です。
ポイント3：第三者のコードやライブラリの扱いを確認する
現代のソフトウェア開発では、オープンソースのライブラリやフレームワークを使用することが一般的です。これらには、それぞれ固有のライセンス条項があります。
確認すべき点
- 使用しているオープンソースライブラリのライセンス種別（MIT、Apache、GPL等）
- ライセンス条件を遵守しているか（著作権表示、ソースコード公開義務など）
- 商用利用に制限はないか
- 開発会社が過去に作成したコード（部品・ライブラリ）を流用していないか
特にGPL系のライセンスは、派生物にも同じライセンスを適用する義務（コピーレフト）があるため、注意が必要です。
ポイント4：ソースコードの引き渡し方法を定める
著作権を譲渡しても、実際にソースコードを受け取らなければ意味がありません。
契約書で定めるべき内容
- ソースコードの引き渡し方法（Gitリポジトリのアクセス権譲渡、ファイル納品など）
- 引き渡しのタイミング（検収完了時、契約終了時など）
- 開発環境の引き継ぎ（構築手順書、環境変数の一覧など）
- 引き継ぎドキュメントの作成義務
「著作権は移転したが、コードは手元にない」という状況を避けるために、引き渡し方法を具体的に定めておきましょう。
ポイント5：契約終了時の取り決めを忘れずに
開発契約が終了した後のことも、事前に取り決めておく必要があります。
確認すべき点
- 契約終了後、開発会社はソースコードを削除する義務があるか
- 開発会社が同様のシステムを他社に提供することの可否
- 保守契約への移行条件
- 将来の改修・機能追加を別会社に依頼することの可否
特に、開発会社が類似システムを他社に提供することを制限したい場合は、競業避止義務や秘密保持義務について明記しておく必要があります。
こんな方は特に注意が必要
以下に当てはまる場合は、著作権トラブルのリスクが特に高くなります。
-
初めてシステム開発を外注する → 契約書の雛形をそのまま使うと、著作権条項が不十分なことが多い
-
フリーランスや個人開発者に依頼する → 契約書なしで進めてしまうケースが多く、トラブルになりやすい
-
「安さ」を重視して開発会社を選んだ → 著作権譲渡のコストが見積もりに含まれていないことがある
-
海外の開発会社に発注する → 適用される法律が異なり、日本の著作権法が適用されない可能性がある
-
アジャイル開発で契約書が曖昧なまま進んでいる → スピード重視で権利関係の整理が後回しになりがち
これらに当てはまる場合は、契約前に専門家（弁護士やIT法務に詳しいコンサルタント）に相談することを強くお勧めします。
開発の外注を検討している方、契約内容に不安がある方は、アトリエ・バイナリでも相談を承っています。技術面だけでなく、契約や権利関係についても、非エンジニアの方にわかりやすくアドバイスいたします。
まとめ：著作権は「知っていれば防げる」トラブル
ソースコードの著作権まとめ
本記事では、ソースコードの著作権に関する基礎知識と、トラブルを防ぐためのポイントを解説しました。
覚えておくべき3つのポイント
1. お金を払っても著作権は自動的に移転しない
著作権は「創作した人」に帰属するのが原則です。発注者が著作権を取得するには、契約で明示的に定める必要があります。
2. 契約書の「著作権譲渡」条項は具体的に
「著作権を譲渡する」とだけ書いても不十分な場合があります。著作権法第27条・第28条の明記、著作者人格権の不行使特約、成果物の具体的な定義など、詳細に記載しましょう。
3. ソースコードの「引き渡し」も契約に含める
著作権を譲渡しても、実際にソースコードを受け取らなければ意味がありません。引き渡し方法、タイミング、開発環境の引き継ぎまで契約で定めておきましょう。
ソースコードの著作権トラブルは、事前の知識と適切な契約があれば防げるものです。
「技術がわからないから、契約内容も開発会社任せにしてしまう」という方も多いかもしれません。しかし、著作権の問題は一度トラブルになると、時間もお金も大きく失うことになります。
契約書を締結する前に、著作権の条項を必ず確認してください。不安な点があれば、遠慮なく開発会社に質問し、必要であれば専門家の助けを借りましょう。
正しい知識を持って契約に臨むことが、あなたのビジネスを守る第一歩です。
