発注者固有成果物、受託者既存資産、OSS、AI支援開発、特許を受ける権利、取引適正まで、企業法務・知財法務で確認すべき論点を整理します。
発注者固有成果物、受託者既存資産、OSS、AI支援開発、特許を受ける権利、取引適正まで、企業法務 ・知財法務で確認すべき論点を整理します。
ソフトウェア開発、AIシステム開発、共同研究、PoCでまず確認すべき権利配分を整理します。
開発成果物の著作権・特許を発注側に帰属させる条項は、単に「知的財産権は発注者に帰属する」と書けば足りるものではありません。成果物の所有権、著作権、著作者人格権、特許を受ける権利、ノウハウ、営業秘密、データ、OSS、第三者素材、従業員や再委託先からの権利承継が一つの条項に混在しやすいからです。
次の重要ポイントは、この条項が何を守るものかをまとめたものです。発注者にとっては将来の改修、ベンダー変更、グループ展開、M&A、監査に直結し、受託者にとっては既存資産と再利用可能性を守るために重要です。中心にある考え方は、発注者固有部分を確保しつつ、受託者の汎用資産と第三者素材を切り分けることだと読み取ってください。
発注者固有成果物の譲渡、受託者既存資産の留保、成果物利用に必要なライセンス、発明の届出と出願協力、OSS・第三者素材の開示、対価と証跡管理を一体で設計する必要があります。
以下の六つの視点は、条項レビューで抜けやすい確認項目です。発注者と受託者のどちらにとっても、各項目が契約文言、別紙、見積書、検収資料に反映されているかを確認することが重要です。ここでは「何を取得するか」だけでなく、「何を除外し、どの範囲で使えるようにするか」を読み取ってください。
ソースコード、設計書、仕様書、画面、DBスキーマ、API仕様、テストコード、学習済みモデル、プロンプト、マニュアル、発明、ノウハウ、素材のどこまでを含めるかを明示します。
複製、翻案、二次的著作物の利用などを確認し、著作権法27条・28条の権利を含めるかを明記します。著作者人格権は譲渡できないため、不行使義務を別に置きます。
登録前の発明には特許権がまだ存在しないため、発明者、受託者、再委託先、従業員から発注者まで権利がつながるようにします。
受託者の汎用モジュール、ノウハウ、OSS、第三者素材を除外しつつ、発注者が事業上必要な利用、保守、改修をできるライセンスを設定します。
中小受託事業者やフリーランスに権利譲渡・許諾を求める場合、範囲を給付内容として明示し、その対価を代金や報酬に反映します。
既存資産リスト、OSS台帳、発明届出、再委託承諾、権利帰属確認書、名義変更、M&A時の証跡管理まで運用設計します。
成果物、著作権、著作者人格権、特許を受ける権利、データを分けて見る章です。
「納品されたから発注者のもの」「代金を払ったから著作権も特許も発注者のもの」という理解は危険です。物やファイルを受け取ることと、著作権や特許を受ける権利を取得することは別の問題として扱う必要があります。
次の比較表は、開発成果物の著作権・特許を発注側に帰属させる条項で混同されやすい権利や情報を整理したものです。権利ごとに移転できるもの、移転できないもの、別途ライセンスや秘密保持で管理すべきものが異なるため重要です。発注者が取得したい対象と、契約で別建てにすべき対象を読み分けてください。
| 対象 | 典型例 | 条項設計の要点 |
|---|---|---|
| 開発成果物 | ソースコード、実行ファイル、設計書、要件定義書、UI、DBスキーマ、API仕様、テスト仕様書、マニュアル、画像、動画、CADデータ、回路図、学習済みモデル、評価レポート | 納入対象として明示するもの、中間成果物として提供するもの、提供しない社内検討資料を分けます。 |
| 中間成果物 | 検討メモ、プロトタイプ、未採用案、試験コード、デバッグ用スクリプト、レビューコメント、学習用一時データ | 保守、監査、セキュリティ検証で必要なら、成果物定義に含めるか、提供資料として扱います。 |
| 著作権 | プログラム、マニュアル、画面デザイン、設計書、文章、画像、動画、データベース | 媒体の所有権とは別です。複製、改変、第三者委託、グループ会社利用、販売、再配布の権限を明確にします。 |
| 著作者人格権 | 公表権、氏名表示権、同一性保持権 | 譲渡できないため、発注者と指定先に対する不行使義務を置きます。創作者や再委託先からの同等合意も必要です。 |
| 特許を受ける権利 | 画像認識、通信制御、セキュリティ処理、製造装置制御、推論処理、IoT省電力制御 | 出願前には特許権がないため、発明届出、譲渡、出願協力、名義変更、外国出願を定めます。 |
| ノウハウ・営業秘密・データ | 技術情報、業務知識、ログ、派生データ、統計データ、モデル改善データ | 一般的な所有権や知的財産権の帰属だけでは整理しきれません。秘密保持、利用範囲、返還・廃棄、学習利用を別途定めます。 |
次の一覧は、発注者に帰属させたい権利と、帰属ではなく利用許諾や秘密保持で処理すべき利益を対比しています。契約上の言葉を使い分けることが、後日の保守、外販、M&A、紛争対応に直結するため重要です。どの項目を譲渡対象にし、どの項目を利用権や管理義務に回すかを読み取ってください。
発注者固有のプログラム、設計書、画面、ドキュメント、発明に関する特許を受ける権利など、発注者の事業固有性が強い成果です。
受託者の既存モジュール、汎用フレームワーク、開発ツール、テンプレートなど、他案件でも再利用される事業資産です。
営業秘密、データ、OSS、第三者素材、AIサービスの利用条件は、権利帰属だけでなく秘密保持、台帳、承認、利用制限で管理します。
委託だけでは移らない著作権、27条・28条、著作者人格権不行使を整理します。
外部ベンダー、個人事業主、制作会社、研究開発会社が成果物を作成した場合、その成果物の著作者または著作権者は受託者側であることが多くなります。発注者が費用を支払ったことは、権利移転を当然に生じさせるものではありません。
次の比較表は、著作権を発注側に帰属させる条項で最低限確認する項目を整理しています。プログラムや設計書は改修、移植、第三者保守、SaaS化の場面で再利用されるため、どの利用行為まで許されるかを明確にすることが重要です。表では、条項に入れるべき論点と、曖昧にした場合の実務上の問題を読み取ってください。
| 論点 | 条項に入れる内容 | 曖昧な場合の問題 |
|---|---|---|
| 委託と著作権移転 | 成果物に関する著作権を誰が、いつ、どの範囲で取得するかを明記します。 | 代金支払や納品だけで著作権移転があったか争われます。 |
| 27条・28条 | 著作権法27条及び28条の権利を含める旨を特掲します。 | 改修、移植、バージョンアップ、二次的著作物利用で権限不足が問題になり得ます。 |
| 著作者人格権不行使 | 受託者、役職員、再委託先、創作者が発注者と指定先に行使しない義務を定めます。 | 名称変更、統合、翻訳、派生開発、非表示化で紛争化する可能性があります。 |
| 利用許諾の選択 | 譲渡が必要な場面と、永続的・取消不能・改変可能なライセンスで足りる場面を分けます。 | 発注者は保守できず、受託者は汎用資産を再利用できない不合理な契約になり得ます。 |
次の判断の流れは、著作権譲渡と利用許諾のどちらを中心に置くかを検討する順番を示します。発注者が必要とする自由度によって最適な条項が変わるため重要です。上から順に、外販・独占・M&A価値まで必要なのか、社内利用と保守が中心なのかを切り分けて読んでください。
社内利用、グループ展開、外販、SaaS提供、M&A対応、競合提供禁止のどこまで必要かを整理します。
業務要件、画面、データ構造、独自アルゴリズム、コンテンツなど競争優位の源泉を特定します。
27条・28条、再許諾、頒布、公衆送信、外国利用まで含めます。
永続的、無償、取消不能、再委託可能、改変可能、グループ利用可能な設計を検討します。
登録前の発明、職務発明、相当の利益、出願協力、ノウハウ秘匿を整理します。
開発委託では、出願前の発明が生じることがあります。画像認識アルゴリズム、通信制御、セキュリティ処理、UI操作方式、製造装置の制御方法、データ圧縮、機械学習モデルの推論処理などでは、特許権だけでなく特許を受ける権利を対象にする必要があります。
次の時系列は、発明が生じてから特許権として管理されるまでの段階を示します。発明者は自然人であり、法人間契約だけでは権利の鎖が途切れる可能性があるため重要です。各段階で、誰から誰へ権利を移す書類や協力義務が必要になるかを読み取ってください。
発明者、創作日、概要、利用した発注者資料、受託者既存技術、共同発明の可能性を記録します。
平成27年改正後の職務発明制度では、契約等であらかじめ使用者等に取得させる定めがある場合、発生時から使用者等に帰属する整理がされています。
受託者、従業員、役員、再委託先、共同研究者から必要な権利譲渡、発明届出、出願協力を取得します。
出願人名義変更、外国出願、拒絶理由対応、分割出願、維持年金、権利行使への協力と費用負担を定めます。
次の注意要素は、特許を受ける権利の移転で紛争や監査指摘につながりやすい点をまとめたものです。登録前の発明、職務発明、共同発明、秘匿ノウハウは、契約文言だけでなく運用記録が必要になるため重要です。どの要素が権利の鎖を弱くするかを読み取ってください。
受託者が特許を受ける権利を持っていなければ、発注者へ譲渡できません。従業員、再委託先、外部研究者からの承継を確認します。
職務発明では、従業者等へ相当の金銭その他の経済上の利益を与える制度が問題になります。後日の請求や協力拒否のリスクになります。
誰が出願国や出願時期を決め、費用を負担し、出願しない場合に秘匿するのかが曖昧だと、新規性喪失や共同発明者同意で問題になります。
出願しないアルゴリズム、パラメータ、製造条件、データ前処理は、秘密保持、再利用制限、リバースエンジニアリング禁止で守ります。
発注者が広い知的財産権の譲渡、独占、競合提供禁止、広範な保証、第三者権利侵害時の補償を求める場合、その内容は価格にも反映されるべきです。知財条項は法務文言であると同時に価格条項でもあります。
次の一覧は、知的財産権の譲渡・許諾を求める場面で特に確認すべき取引適正上の視点です。中小受託事業者やフリーランスとの契約では、範囲と対価の不明確さが後日のコンプライアンスリスクになるため重要です。各制度が求める「範囲明示」「対価反映」「一方的な低額設定の回避」を読み取ってください。
情報成果物作成委託で中小受託事業者に知的財産権が発生する場合、譲渡・許諾の範囲を明示し、対価を代金に加える必要があると整理されています。
個人事業主等に成果物の権利譲渡・許諾を求める場合、二次利用、独占性、期間、地域、第三者提供、改変、不行使義務を説明し、報酬に反映します。
契約後に無償譲渡、追加対価なしの競合提供禁止、当初予定を超える全国販売を求めると、取引上の問題になり得ます。
次の比較表は、対価と証跡を残すために契約書以外でそろえる資料を整理したものです。契約条項だけが整っていても、見積・発注・検収・請求の記録と矛盾すると説明が難しくなるため重要です。どの資料にどの範囲と金額を反映すべきかを読み取ってください。
| 資料 | 反映する内容 | 実務上の意味 |
|---|---|---|
| 契約書・個別契約 | 譲渡対象、利用許諾範囲、独占性、移転時期、第三者素材、OSS、保証、補償 | 権利配分の中心文書になります。 |
| 見積書・発注書 | 著作権譲渡対価、特許を受ける権利の譲渡対価、独占利用対価、競合提供制限対価 | 対価が委託料に含まれるのか別建てかを説明します。 |
| 検収書・請求書 | 納品対象、権利移転時期、支払条件、追加利用の有無 | 移転時期や支払完了時移転の条件を確認する資料になります。 |
| 稟議・交渉記録 | 権利範囲の協議、追加対価の理由、価格交渉の経緯 | 一方的な低額設定ではないことを示す証跡になります。 |
四層分解、成果物定義、利用許諾併用、競合提供制限を整理します。
実務上有効なのは、成果物を一つのかたまりとして扱うのではなく、発注者固有成果物、受託者既存資産、第三者素材・OSS、ノウハウ・非公開情報に分けて帰属と利用権を設計する方法です。
次の比較表は、開発成果物を四つの層に分けて、帰属・利用・管理の方法を整理したものです。発注者の自由な利用と受託者の事業継続を両立させるために重要です。各層ごとに、発注者へ譲渡すべきもの、受託者に留保しつつ利用許諾すべきもの、ライセンス条件に従うべきものを読み取ってください。
| 層 | 内容 | 推奨される設計 |
|---|---|---|
| 発注者固有成果物 | 発注者固有の業務要件、画面、データ構造、仕様、独自アルゴリズム、ブランド、コンテンツ、研究成果 | 著作権譲渡、特許を受ける権利の譲渡、ノウハウの帰属または排他的利用権を検討します。 |
| 受託者既存資産・汎用資産 | フレームワーク、共通部品、ライブラリ、テンプレート、テストツール、開発手法、監視ツール、ノウハウ | 受託者に留保し、発注者に成果物利用に必要な範囲で永続的・非独占・無償・改変可能なライセンスを付与します。 |
| 第三者素材・OSS | OSS、商用ライブラリ、フォント、素材集、SDK、API、クラウドサービス、AIツール | 権利譲渡ではなく、ライセンス条件、台帳、SBOM、承認、通知義務、代替措置で管理します。 |
| ノウハウ・非公開情報 | 発注者の秘密情報、受託者のノウハウ、共同で得た知見、失敗実験データ、性能評価結果 | 再利用可否、秘密保持、返還・廃棄、統計化、モデル改善利用を分けて定めます。 |
次の判断の流れは、成果物定義から競合提供制限までを順に設計する手順を示します。広すぎる帰属条項はかえって紛争を招くため、定義と除外を同時に置くことが重要です。上から順に、納入対象、除外対象、利用権、競合制限の範囲を読み取ってください。
個別契約、仕様書、発注書、電磁的記録で納入・提供対象を特定します。
既存プログラム、ライブラリ、テンプレート、ノウハウ、開発ツール、汎用モジュールを別紙または定義で除外します。
利用、保守、運用、複製、改変、翻案、第三者委託、バックアップ、グループ会社利用を目的に合わせて定めます。
秘密保持、非使用、類似成果物提供制限、競業避止を、期間、地域、対象顧客、対象技術に絞って定めます。
発注者側に強い基本形、バランス型、研究開発委託型を条項要素に分けて整理します。
条項例は、案件ごとに移転時期、対価、既存資産、第三者素材、OSS、職務発明、再委託先、税務・会計、国外法を調整する必要があります。ここでは、文言をそのまま使うのではなく、条項が担う機能を確認します。
次の比較表は、発注者側の権利確保を重視する基本形を項番ごとに整理したものです。発注者帰属を基本にしつつ、受託者既存資産と第三者素材を除外し、必要な利用許諾を確保する構造が重要です。どの項番が著作権、特許、人格権、第三者素材、権利処理を担うかを読み取ってください。
| 項番 | 条項化する内容 | 実務上の狙い |
|---|---|---|
| 1 | 成果物を、納入・提供対象として合意されたプログラム、ソースコード、設計書、仕様書、画面、画像、文章、DB、テストコード、マニュアル、レポート等と定義します。 | 何が譲渡・利用許諾の対象になるかを特定します。 |
| 2 | 成果物の著作権を、27条・28条の権利を含め、作成時または納入時に発注者へ移転させる旨を定めます。 | 改修、翻案、二次利用を含む利用権限を確保します。 |
| 3 | 受託者が契約締結前から保有し、または業務とは独立して開発した既存資産を除外します。 | 受託者が汎用資産を失う不合理を避けます。 |
| 4 | 既存資産が成果物に含まれる場合、発注者と指定先へ目的達成に必要な利用権を付与します。 | 保守、運用、複製、改変、第三者委託、グループ会社利用を可能にします。 |
| 5 | 受託者と関与者が著作者人格権を行使しない義務を定めます。 | 名称変更、統合、分割、翻訳、派生開発の障害を減らします。 |
| 6 | 発明、考案、意匠等が生じた場合の通知、特許を受ける権利等の移転、手続協力を定めます。 | 登録前の発明を発注者へつなげます。 |
| 7 | 役職員、再委託先、第三者から必要な権利処理を完了していることを表明保証させます。 | 権利の鎖が途切れるリスクを抑えます。 |
| 8 | 第三者ソフトウェア、OSS、第三者素材の名称、権利者、ライセンス条件、利用形態、制約を事前開示させます。 | 譲渡できない権利を譲渡保証する構造を避けます。 |
次の比較表は、発注者側に強い基本形とは異なる二つの型をまとめたものです。受託者の事業継続や研究開発型の発明管理では、全面譲渡よりも固有部分と汎用部分の切り分け、出願協力、秘匿化の決定権が重要です。案件の性質に応じて、どの型を土台にするかを読み取ってください。
| 型 | 中心となる条項要素 | 向いている案件 |
|---|---|---|
| 受託者側とのバランス型 | 発注者資料、データ、仕様、業務情報、商標、コンテンツに基づく発注者固有部分は発注者帰属。受託者汎用部分は受託者に留保し、発注者へ保守・改修・移行・監査等に必要な利用権を付与します。 | 業務システム、コンサル成果物、受託開発など、受託者の共通部品と発注者固有部分が混在する案件です。 |
| 研究開発委託型 | 発明者、創作日、概要、共同発明の可能性、出願希望国を報告させ、特許を受ける権利を発注者に帰属させ、出願・審査・維持・権利行使への協力を定めます。 | AI・アルゴリズム、ハードウェア制御、医療機器、素材、半導体、通信、ロボティクスなど発明管理が中心となる案件です。 |
| 秘匿ノウハウ重視型 | 出願しない技術成果を秘密情報として扱い、受託者による自己利用・第三者利用を制限し、秘密保持と記録管理を強化します。 | パラメータ、製造条件、データ前処理、モデル評価方法など、出願より秘匿が有利な案件です。 |
譲渡できない素材、ライセンス条件、AI支援開発の確認事項を整理します。
受託者が全面譲渡に慎重になるのは、単なる交渉上の抵抗ではありません。既存ライブラリ、開発基盤、テンプレート、コードジェネレータ、テストフレームワーク、運用監視スクリプト、UI部品、開発方法論、ノウハウは複数顧客に提供する事業資産だからです。
次の一覧は、OSS、第三者素材、AI支援開発で契約上分けて管理すべき対象をまとめたものです。これらは発注者帰属条項があっても当然に著作権移転できるものではないため重要です。各対象について、譲渡ではなくライセンス条件、事前承認、台帳、検証義務で管理する点を読み取ってください。
自由に使用・改変・共有できる条件付きライセンスであり、権利放棄や所有権移転ではありません。通知義務、ライセンス文書添付、特許訴訟時の終了条項などを確認します。
台帳SBOM画像、アイコン、フォント、音源、地図、辞書データ、SDK、クラウドサービス、商用ライブラリは、社内利用、Web利用、アプリ組込み、改変、再配布の可否を確認します。
承認再配布次の比較表は、OSS・第三者素材・AI支援開発を契約で管理するための具体項目を整理したものです。将来の外販、SaaS提供、海外展開では、素材の権利制限が後から発覚すると事業計画に影響するため重要です。どの情報を事前開示させ、どの義務を受託者に置くかを読み取ってください。
| 対象 | 契約で定める項目 | 確認すべきリスク |
|---|---|---|
| OSS | 名称、バージョン、ライセンス名、利用形態、配布有無、ソースコード開示義務、特許ライセンス条件、脆弱性対応、代替部品提供 | GPL系、AGPL系、LGPL系、MPL系、SSPL系、Apache License 2.0などで条件が異なります。 |
| 第三者素材 | 権利者、利用範囲、改変可否、地域、ユーザー数、サブライセンス、商用利用、Web・アプリ利用、ロゴ利用 | 社内利用は可能でも再配布不可、Web利用は可能でもアプリ組込み不可といった制限があります。 |
| AI支援開発 | 事前承認、利用ツール名、入力禁止情報、出力物検証、第三者権利侵害の保証範囲、プロンプト・ログ保存、学習利用オプトアウト | AI生成物に著作物性が認められるか、類似コードが混入していないか、利用規約が商用利用を認めるかが問題になります。 |
発注者側・受託者側の合理的な落とし所、対価説明、典型的な失敗を整理します。
交渉では、発注者が最初から全部譲渡に固執するより、事業上必要な自由を言語化する方が安定します。受託者側も単に譲渡できないと拒むのではなく、留保したい既存モジュール、汎用フレームワーク、ノウハウ、開発ツール、OSS、第三者素材、自社プロダクト連携部分を特定することが重要です。
次の一覧は、交渉で整理すべき三つの視点を示しています。権利範囲と対価が対応していないと、発注者には将来利用の不足が残り、受託者には過大な保証や再利用制限が残るため重要です。各立場で何を言語化すべきかを読み取ってください。
社内利用、グループ展開、外販、独占利用、保守ベンダー変更、ソースコード改変、特許出願、競合提供禁止、M&A承継の要否を整理します。
標準コード、既存ライブラリ、汎用ノウハウ、開発ツール、第三者素材、OSSについて、譲渡できないものとライセンス可能なものを分けます。
全部譲渡、独占、競合提供禁止、広範な保証、全面補償を求める場合は、著作権譲渡対価、特許を受ける権利の譲渡対価、独占利用対価を明記することがあります。
次の注意要素は、契約レビューや紛争で見つかりやすい典型的な失敗をまとめたものです。いずれも強そうな文言や納品物の受領だけでは実務上の権利確保にならない点が重要です。どの失敗が発注者側の利用不足、受託者側の過大負担、第三者権利侵害につながるかを読み取ってください。
27条・28条、著作者人格権不行使、特許を受ける権利、既存資産、第三者素材、OSS、対価、手続協力が抜けます。
受託者が契約を拒む、価格が上がる、納品後に既存モジュールの扱いで争う、といった問題につながります。
著作権を取得してもソースコードがなければ保守できず、ソースコードがあっても改変許諾がなければ自由に使えません。
外部フリーランス、海外開発会社、デザイナー、研究者が権利を持ったままになる可能性があります。
出願国、費用、外国出願、出願しない場合の秘匿、新規性喪失、共同発明者同意で問題が生じます。
OSS部分の著作権は移転せず、配布形態によってソースコード開示、ライセンス表示、特許ライセンス条件が問題になります。
外販、SaaS、OEM、アプリストア配信、API提供、海外配布を予定する場合は、社内利用とは必要な権利が異なります。複製、翻案、公衆送信、譲渡、再許諾、サブライセンス、商標表示、OSS再配布、輸出管理、個人情報、セキュリティ脆弱性、第三者特許侵害リスクまで契約時に検討する必要があります。
チェックリスト、移転時期、紛争時の証拠、M&A・資金調達での確認資料を整理します。
条項を作った後は、開発開始前、開発中、納品時、検収後、M&A・資金調達時まで証跡を残す必要があります。契約締結時の合意だけでは、発明者、再委託先、OSS、既存資産の記録が不足する可能性があります。
次の比較表は、著作権や特許を受ける権利をいつ移転させるかという交渉点を整理しています。移転時期は発注者の倒産・二重譲渡リスクと、受託者の未払いリスクの配分に関わるため重要です。各方式の利点と、別途補うべき利用許諾や支払条件を読み取ってください。
| 方式 | 特徴 | 補うべき点 |
|---|---|---|
| 作成時移転 | 成果物の作成時に発注者へ移転するため、発注者にとって強い方式です。 | 受託者は未払いでも権利が移るリスクを負うため、解除時の利用停止、損害賠償、支払条件を検討します。 |
| 納入時移転 | 納入されたものについて権利を移すため、成果物の特定が比較的しやすい方式です。 | 検収前の扱い、検収不合格時の扱い、部分納品時の権利範囲を定めます。 |
| 検収完了時移転 | 受託者は未検収・未完成の成果物について権利を保持できます。 | 発注者が検収前に試験利用・社内検証・第三者レビューを行うための利用許諾を別途定めます。 |
| 支払完了時移転 | 委託料全額の支払完了時に移転するため、受託者に有利です。 | 支払前の利用権、分割支払時の部分移転、受託者倒産時、支払保留時の扱いを検討します。 |
次の時系列は、契約締結から監査・M&Aまで、権利帰属条項を実際に機能させるための管理手順を示します。条項だけでなく証跡が企業価値や紛争予防を支えるため重要です。各段階で、どの資料を残すべきかを読み取ってください。
受託者既存資産リスト、OSS台帳、第三者素材一覧、再委託承諾、職務発明規程を確認します。
発明届出、Git履歴、課題管理、実験ログ、AIツール利用ログ、SBOM、ライセンス条件を更新します。
納品書、検収書、権利帰属確認書、譲渡証書、著作者人格権不行使、ビルド手順、環境構築手順をそろえます。
開発委託契約、個別契約、職務発明規程、再委託契約、OSS台帳、特許出願書類、名義変更書類、従業員誓約書を提示できるようにします。
紛争では、契約文言、見積書、仕様書、議事録、メール、発注書、納品書、検収書、ソースコード履歴、創作者、開発経緯、代金額、業界慣行、当事者の交渉力が総合的に見られます。M&Aや資金調達でも、古い雛形に27条・28条がない、フリーランスとの口頭合意だけ、OSS台帳がない、特許出願名義が創業者個人のままといった問題は、価格調整や追加調査につながることがあります。
よくある疑問を一般情報として整理します。個別案件では資料を確認して専門家へ相談する必要があります。
一般的には、それだけでは十分でないと評価される可能性があります。譲渡対象、27条・28条、著作者人格権不行使、受託者既存資産、第三者素材、OSS、移転時期、再委託先権利処理を併せて定める必要があります。取適法・フリーランス法の対象では、譲渡・許諾の範囲を明示し、対価を代金・報酬に反映することが重要です。ただし、契約類型や交渉経緯によって評価は変わる可能性があり、具体的な対応は弁護士等の専門家へ相談する必要があります。
一般的には、ソースコードの納品と著作権・改変許諾は別に整理されます。ソースコードがあっても、複製、改変、翻案、第三者委託、再配布の権限がなければ利用が制限される可能性があります。ただし、契約目的や既存の許諾範囲によって結論は変わるため、具体的な対応は資料を整理したうえで弁護士等の専門家へ相談する必要があります。
一般的には、除外の仕方によって実務上の影響が変わります。既存モジュールの権利を受託者に残しても、発注者が成果物を利用・保守・改修・移行するために十分なライセンスを受ければ、目的を満たせる場合があります。もっとも、除外範囲や利用許諾が曖昧だと紛争化する可能性があるため、具体的な対応は弁護士等の専門家へ相談する必要があります。
一般的には、自動的に発注者へ帰属するとは限りません。発明者から受託者、受託者から発注者へ権利が移る契約、職務発明規程、譲渡手続、出願協力が必要になることがあります。発明者、共同発明、再委託先、外国出願の有無で結論は変わるため、具体的な対応は弁理士や弁護士等の専門家へ相談する必要があります。
一般的には、著作者人格権は著作者に専属し、譲渡できないものとされています。そのため、契約では不行使義務を定め、受託者の役職員や再委託先にも同等の合意を求める設計が検討されます。ただし、不行使条項の範囲や運用によって紛争化する可能性があるため、具体的な対応は弁護士等の専門家へ相談する必要があります。
一般的には、OSS部分の著作権を発注者へ譲渡することは通常想定されず、OSSライセンスに従って利用する整理になります。成果物全体のうち、受託者が創作した部分について譲渡や利用許諾を受け、OSS部分についてはライセンス表示、ソースコード開示、特許ライセンス条件などを確認します。具体的には利用形態や配布形態で結論が変わるため、専門家へ相談する必要があります。
一般的には、契約上、受託者が有する権利や利用権を発注者に移転・許諾する設計は考えられます。ただし、AI生成物に著作物性が認められるか、第三者著作物に類似しないか、AIサービス利用規約が譲渡・商用利用を認めるか、入力情報が秘密保持に反しないかは別途確認が必要です。個別の利用条件によって判断が変わるため、具体的な対応は弁護士等の専門家へ相談する必要があります。