システム開発では、サーバ等の有体物の所有権、プログラム／UI／マニュアルの著作権（著作者人格権を含む）、そして場合によっては特許が同時に絡み合います。本稿は、取引先との関係と社内（従業員）との関係を切り分け、原則と交渉パターン、条項化の注意点を具体的に解説します。
とりわけ著作権の扱いを最重要テーマとして位置づけ、費用負担の有無にかかわらず創作した側に原則帰属すると整理し、実務上は①ベンダ帰属、②ユーザ帰属、③分離帰属、④共有の四つの着地点で交渉がまとまることを示します。
ただし、共有を選ぶと全員同意がなければ権利を行使できないため、運用が止まる危険が高まります。
したがって、まずは複製・翻案・サブライセンスなどの利用ライセンスを設計して実需を満たす発想に切り替えることをご提案します。
次に、著作者人格権は譲渡できないため、改修や再利用の摩擦を避ける目的で「行使しない」特約をあらかじめ置くことをお勧めます。
一方で特許の共有は単独で実施できるものの、第三者へのライセンス付与には同意が必要になるという、著作権共有と正反対の運用になる点に注意を促します。また、社内では、著作権が職務著作として原則会社に帰属しやすいのに対し、特許は職務発明として従業員に帰属しやすいという対照性が生じるため、契約・就業規則・社内規程を連動させて外部への約束を確実に履行できる体制を整える必要があります。
以上を踏まえ、「単独帰属＋十分なライセンス設計」を起点に、人格権不行使特約を整備し、職務著作・職務発明の社内ルールを明確化し、特許と著作権の共有規律の違いを契約に織り込むことで、改修・再利用・再委託に強い権利設計を実現できます。
こんな方に役立ちます
・「共有にすれば公平だ」と考えて契約を進めてしまうことがある場合は、より安全な代替案を理解できます。
・ソースコードの開示と著作権の帰属を同一視してしまうことがある場合は、誤解を解消できます。
・費用負担と権利帰属を自動的に結びつけて考えてしまうことがある場合は、原則と例外を整理できます。
・社内の職務著作・職務発明の取扱いが未整備で不安を抱える場合は、整備の具体的な優先順位を把握できます。
|
|
弁護士 湯原伸一
