知的財産・著作権・OSS

あなたが書いたコードの著作権は、最初はあなたのものです。

会社員時代とは違います。会社員のコードは職務著作として会社のものになりますが、 それは雇用関係が前提の制度です。業務委託には適用されません。

著作権は、契約で譲渡しない限り、創作した本人に残る

だからこそ、契約書に権利の帰属条項が入ります。この章はその読み方です。

著作権の基本

よくある権利帰属条項

パターン1: 全部譲渡（発注者に有利）

「本件成果物に関する著作権（著作権法第27条および第28条の権利を含む）は、
 甲による検収完了時をもって、甲に移転する」

著作権法 第27条 … 翻訳権、翻案権等
著作権法 第28条 … 二次的著作物の利用に関する原著作者の権利

パターン2: 著作者人格権の不行使

「乙は、甲および甲が指定する第三者に対して、著作者人格権を行使しない」

著作者人格権は譲渡できないため、不行使特約という形が使われます。 実務上は一般的な条項です。

パターン3: 汎用部分の留保（受注者に有利）

「前項にかかわらず、乙が本契約以前から保有していた著作物、および
 汎用的に利用可能なプログラム・ライブラリ・ノウハウに関する権利は乙に留保される。
 乙は甲に対し、本件成果物の利用に必要な範囲で、これらの使用を許諾する」

この条項を入れる交渉は、必ずしてください。

なぜ汎用部分の留保が重要か

自作のユーティリティライブラリを案件Aで使った
  → 全部譲渡の契約だと、その著作権は発注者Aに移る
  → 案件Bで同じライブラリを使うと、Aの権利を侵害する可能性

これが積み重なると、自分の資産を1件ずつ手放していくことになる

「成果物の著作権は貴社に譲渡します。ただし、私が以前から保有している
 汎用的なライブラリやユーティリティについては、私に権利を留保させてください。
 貴社には、成果物の利用に必要な範囲でライセンスをお渡しします」

職務著作は適用されない

職務著作の要件（法人等が著作者になる場合）:
  □ 法人等の発意に基づく
  □ 法人等の業務に従事する者が職務上作成する
  □ 法人等の名義で公表される
  □ 契約・勤務規則に別段の定めが無い

「業務に従事する者」は雇用関係が基本です。 業務委託のフリーランスは通常これに当たらないため、 契約で譲渡しなければ権利は移りません。

OSS との関係

業務で OSS を使う時、ライセンスの確認は受注者の責任になることが多いです。

□ 依存関係のライセンスを一覧化する（ライセンススキャンツールを使う）
□ 契約書に「第三者の権利を侵害しないことを保証する」条項があるか確認する
□ 保証している場合、その責任は自分が負う

生成 AI で書いたコード

□ 生成 AI の利用が契約・NDA で禁止されていないか確認する
□ 学習データ由来のコードが混入するリスクを認識する
□ 発注者のコードを AI サービスに送信してよいか（秘密保持の問題。[秘密保持と競業避止](/chapters/nda-and-non-compete/)）

特許・その他の権利

□ 発明が生まれる可能性がある案件では、特許を受ける権利の帰属も条項に入る
□ 商標・意匠が関わる場合も同様
□ ノウハウ（営業秘密）の扱いは秘密保持条項で規定される

ポートフォリオへの掲載

□ 秘密保持契約により、案件名すら出せないことがある
□ 「実績として公表してよいか」を契約時に確認しておく
□ 公表可の範囲（社名まで／業種まで／技術スタックのみ）を明確にする

この章のまとめ

• 著作権は創作した本人に発生する。職務著作は雇用関係が前提で、業務委託には適用されない
• 譲渡条項には著作権法27条・28条の明記があるのが通常
• 著作者人格権は譲渡できないため、不行使特約が使われる
• 汎用ライブラリの留保条項は必ず交渉する。発注者が欲しいのは使う権利であって独占ではない
• OSS のライセンス確認は受注者の責任になることが多い。GPL/AGPL は特に注意
• 生成 AI への入力が秘密保持義務に触れる可能性がある。契約を確認する
• 実績公開の可否は契約時に決める。後から聞くと通りにくい

参考資料