Intellectual Property
SaaSの個別開発で著作権譲渡を求められたら――共通機能の更新・他社提供を続けるための確認点
一社向けの開発契約でも、共通部分に関する権利が譲渡され、他の顧客への提供・更新に必要な利用が認められていなければ、共通サービスの運営に影響します。譲渡の範囲、自社に残る利用の条件、他社への提供を制限する条項を、併せて確認します。
監修：吉川 景司（弁護士・弁理士／第一東京弁護士会）
1 今回の作業と、他の顧客への影響の整理
まず、今回の作業が既存の共通部分に触れるか、その結果を他の顧客にも提供する予定があるかを整理します。
はじめに、開発前から存在する部分について、譲渡の対象から除く範囲を確認します。既存のサービス基盤、共通のライブラリ、過去の案件で作った部品、社外から取得して組み込んでいる部分。これらを対象から外す記載が契約書にあるか、外し方が具体的かを見ます。「当社が従前から有する著作物」と定める場合も、どの時点の、どの版を基準にするかを決め、対象を特定できる形にします。
そのうえで、今回の作業を次のように整理します。
今回の作業と、提供の予定
| 今回の作業 | 当該顧客だけに提供する予定 | 他の顧客にも提供する予定 |
|---|---|---|
| 既存部分を改修する | 改修が他の顧客の利用環境にも反映されないか | 既存部分の留保に加え、改修後の他社提供を認める条件があるか |
| 新たな部分を作成する | 対象の記載が共通部分を含んでいないか | 新規部分を共通サービスに組み込み、他社にも提供できる条件があるか |
一つの案件で、既存部分の改修と新たな部分の作成の両方を行うことがあります。作業ごとに該当する行を使います。「提供」には、その部分を組み込んだサービスとして顧客に利用させる場合も含みます。この表は、今回の作業と提供の予定を整理するものです。各欄によって著作権の帰属や利用の可否が決まるわけではありません。
確認は機能から入り、それを実装するコード、設計資料、対象の版、変更した箇所に対応させます。契約の時点で完成後のコードまで特定する必要はありません。対象の決め方を先に合意し、設計と開発が具体化するのに応じて、対応を残していきます。
なお、著作権が保護するのはコードなどの創作的な表現であり、似た機能であることだけで侵害になるわけではありません。類似の機能を開発・提供することが契約上の禁止に当たるかは、別に確認します。
2 譲渡する範囲と、自社が続けられる利用の決定
顧客が譲渡によって何を確保したいのかを確かめ、その目的と、自社に必要な利用を両立できる条件を検討します。継続して使い続けたいのか、他の顧客への提供を制限したいのか、ソースコードを手元に置きたいのか。目的が分かれば、その要求を受け入れても共通サービスの提供・更新を続けられるか、という検討に進めます。
まず検討するのは、共通部分の権利を自社に留保する構成です。譲渡の対象を顧客専用の部分に限り、開発前から存在する部分と、今回作った共通部分について、自社に帰属する権利を残します。これは、いったん譲渡したうえで使わせてもらう構成とは別です。留保できるなら、後から確保すべき利用条件は少なくなります。
譲渡する部分がある場合は、自社が続けられる利用を、行為ごとに確認します。複製すること、改修すること、改修した版を使うこと、他の顧客向けのサービスに組み込むこと、外部の開発・保守の委託先に作業させること。行為ごとに、認められる期間と、顧客との契約が終了した後も続けられるかを決めます。「自社の事業のために利用できる」という文言に、予定する行為が含まれるかを確認します。
このとき、当該顧客への提供だけを認める条件と、他の顧客への提供も認める条件を区別します。前者だけでは、譲渡した部分を他の顧客向けにも利用するための許諾にはなりません。改修した共通部分が他の顧客の環境にも反映される構成であれば、その反映自体が認められているかを確かめます。
外部の開発者に作らせた部分については、顧客への譲渡と自社の継続利用に必要な権利を、その開発者から確保できているかを先に確かめます。外部の開発者に権利が残っている場合、顧客との譲渡合意だけでは、その権利は移りません。委託先との契約が、今回の顧客への譲渡まで予定した内容になっているかを見ます。
必要な利用を確保できない場合は、契約の条件だけでなく、開発の範囲や提供の方法も見直します。共通部分に触れない実装にできるか、その顧客の環境に限って提供できるか。いずれも難しければ、その条件で受けてよいかを社内で判断します。既存の顧客への提供・更新や、今後の他社展開への影響を、営業・開発も交えて見積もります。
なお、顧客が取引上の強い立場を利用して、正当な理由のない著作権の無償譲渡を求め、自社が取引への影響を懸念して応じざるを得ない状況では、取引上の規制が問題になることがあります。受け入れにくい条件であることと、規制に違反することは別です。
3 著作権を自社に残した場合の、他社提供の制限
著作権を自社に残す合意があっても、別の条項で類似の機能の開発や他社への提供を制限していないかを確認します。権利の帰属だけを見ても、この問題は判断できません。
確認するのは三つです。第一に、禁止の対象が顧客専用の処理だけか、既存の権限管理などの共通機能まで含むか。第二に、新規の顧客への提供だけか、既存の顧客への提供の継続や機能の更新も対象になるか。すでに提供している顧客への更新まで止まると、影響は今回の案件にとどまりません。第三に、制限の期間と、対象となる顧客や市場が、自社の予定する共通サービスの展開と衝突しないか。
既存の顧客への提供・更新など、継続したい利用が制限に当たる場合は、制限の範囲を調整できるかを検討し、その結果も受注の判断に反映します。
条項の書き方によっては、コードを別に書いても、同等の機能を開発・提供したことが約束への違反として問題になります。著作権を侵害していないことと、契約に違反していないことは、別に確かめます。
秘密保持についても、自社に権利を残した部分であれば顧客の秘密情報を他社向けに利用してよい、とは限りません。
4 仕様変更を採用する前の、合意した範囲とのずれの確認
社内で後から共通機能と位置付けても、顧客との合意内容が変わるわけではありません。当初は他の顧客への提供を予定していなくても、契約がそれを許している場合があります。提供の方針を変えるときは、当初の合意の範囲に収まるかを確認します。
権利の扱いや提供の範囲に影響する仕様変更は、採用する前に、営業・開発・法務で合意との関係を確認します。確認する時点は、完成後や他の顧客への提供の直前だけではありません。仕様を決める段階で、その変更が譲渡の対象や利用の条件に触れるかを見ます。
範囲を超える場合は、顧客との調整に戻ります。何を対象とし、どの利用を確保する合意だったのかを示せるよう、判断の理由と、誰がいつ確認したかを残します。契約の締結時に決めた対象の決め方と、その後の設計・開発でそれをどう当てはめたかが、後から追えることが要点です。合意した範囲に収まる共通化まで、そのつど顧客の承諾を求める必要はありません。
著作権譲渡の要求に応じるかどうかは、譲渡の範囲、自社に残る利用の条件、他社提供を制限する条項を併せて見なければ判断できません。当事務所では、開発契約の権利条項の確認、譲渡範囲と自社に残す利用条件の設計、顧客との契約交渉について、個別のご相談をお受けしています。
開発契約全体の変更管理や紛争予防については、システム開発紛争への対応をご覧ください。
Contact
ご相談にあたって
現在の状況、受領している通知があればその内容と日付、把握している期限を、分かる範囲でお知らせください。
お問い合わせフォームへ本記事は一般的な情報提供を目的とするものであり、個別の事案に関する法的助言ではありません。具体的な対応については、当事務所までご相談ください。記事の内容は、最終更新日の時点で施行されている法令等に基づいています。施行前の改正法を取り上げる場合は、本文にその旨を示しています。