アドベントカレンダーの1人フルマラソンに挑戦中です😃
翌日はこちら：（これから書く）
前日はこちら：著書はペンネーム、技術イベント登壇は芸名でOK？会社が却下できない氏名表示権【著作権法】
ソースコードの特殊性
あなたが今年、会社で書いたソースコード。一体誰の物になるのか、意識したことはありますか？
ソースコードは、著作物としては特殊で例外的なものです。
既存のソースコード（著作物）を少し改変して、新たなソースコード（著作物）を作る
ソースコードでは、このような特別な利用方法があらかじめ予定されています。
はるか昔の平安時代、「源氏物語」を読者が順番に書き写すとき、ストーリーを勝手に書き換えて「異本」にしてしまうことがあったそうです。現代でいう「二次創作」ですね。しかし、ソースコードほど（複数人の手で）頻繁に書き換えられ新たな「二次創作」が派生し続ける著作物は、他に例がないのではないでしょうか。
特殊な物を扱うには、相応の特殊なルールが必要です。たとえば、「物質」の中では特殊な「放射性物質」を扱うためのルールがあり、ルールを守らないと事故が起きかねません。
ありがたい事に、現代の著作権法のルールとその解釈にはソースコードの特殊性がすでに折り込まれています。
しかし、一般的な著作物とは違う特殊ルールなので、「誰の物」か分かりづらくなったり、それが原因でトラブルが発生しがちです。また、日本で多用される複数ベンダー参画（多重請負を含む）によるシステム開発手法も、混乱させる要因になっています。
ソースコードを著作物として適切に扱うことは 「コードを書くエンジニア」の責務です。適切に扱うには、その特殊性とルールを理解する必要があります。
少しずつ紐解いて見ていきましょう。
著作者と著作権者
まず、「ソースコードは誰の物か？」と考えるとき、「誰」は「著作者」または「著作権者」となります1。「著作者」と「著作権者」は使い分けが必要です。
- 著作者とは
- 原則、著作物（ソースコードのように創作性のあるもの）を作った個人のこと
- 著作者人格権を持ち、他人には譲渡できない（著作者人格権は昨日の"氏名表示権"の記事で紹介しました）
- 著作権を持ち、他人に譲渡することができる
- 著作権者とは
- 著作者本人。または、著作者から著作物にかかる著作権の一部または全部を譲渡された人物, 法人等。
これらのルールから、以下の状況が発生します。
- 最新コミット
abcd1234を書いた社員エンジニアAは、ソフトウェアバージョンabcd1234全体の著作者・著作権者であり、著作者人格権・著作権を有している - 最新コミット
abcd1234の親コミットefgh5678を書いた社員エンジニアBは、ソフトウェアバージョンefgh5678全体の著作者・著作権者であり、著作権・著作者人格権を有している - 社員エンジニアAは、社員エンジニアBに対して、ソフトウェアバージョン
efgh5678の複製と改変の許諾を得なければならない - 会社はソフトウェアをリリースするたびに、各バージョンの著作者である社員AやBより、ソフトウェアの著作権の譲渡を受けなければならない。
…めちゃくちゃめんどくさいですね😑
また、仮にソースコードをコミットした瞬間に「著作権」が社員から会社に譲渡するよう契約を結んだとしても、「著作者人格権」のほうは法律上譲渡できません。
例えば、社員AやBが持つ「公表権」を使い、会社の意に反してソースコードを公開することができてしまいます。恐ろしい話ですね。
職務著作（法人著作）
このようなめんどくささを解消するために利用できるのが「職務著作」というルールです。個人が「著作者」になるという原則の例外パターンになります。
以下の要件をすべて満たした場合に限り、創作活動を行った個人が属している会社等が「著作者」となれます。（文化庁 - 著作者についてより引用）
(1)その著作物を作る企画を立てるのが法人その他の使用者であること。
(2)法人等の業務に従事する者の創作であること。
→部外者に委嘱して作成された場合など，会社との間に支配・従属関係にない場合は除かれる。
(3)職務上作成されること
→具体的に作成することを命じられた場合に限られ，大学教授の講義案のように，その職務に関連して作成された場合は除かれる。
(4)公表するときに法人等の名義で公表されること
→通常，コンピュータプログラムの場合には，公表せずに利用するものが多いため，この要件を満たす必要は無い。
(5)契約や就業規則で職員を著作者とする定めがないこと。
会社が「著作者」になり、同時に「著作権者」にもなることでソースコードを掌握できます。社員も手間とリスクを省けて安心でしょう。この場合でも厳密には社員がコミットするたびに会社に許諾が必要となりそうですが、プルリクエスト（マージリクエスト）の承認を以て許諾とみなしたり、あるいは暗黙的に会社の許諾を得ていると解釈すれば問題無さそうです。
なお、文化庁による解釈の中で以下の部分に着目すると、「職務著作」の要件を満たすためには、詳細設計書等による具体的なソースコード作成指示が必要なのでは？と思われるかもしれません。
(3)職務上作成されること
→具体的に作成することを命じられた場合に限られ，大学教授の講義案のように，その職務に関連して作成された場合は除かれる。
しかし、プログラムに関する判例 では具体的な作成指示がなくても、職務上著作物の作成が予定・予測されていれば、職務著作の要件に一致するとみなされるようです。
開発委託等と職務著作
それから、文化庁による解釈の中でもう一点留意すべきところがあります。
(2)法人等の業務に従事する者の創作であること。
→部外者に委嘱して作成された場合など，会社との間に支配・従属関係にない場合は除かれる。
部外者に「委嘱」とは具体的にどういうことでしょうか？契約種別ごとに見ていきましょう2。
請負契約の場合
ソースコード作成業務を請負契約で他社に委託したとき、発注元会社の職務著作にはならないので、発注元会社は「著作者」にはなりません。
発注先会社が職務著作の要件を満たせば「著作者」になりえて、そうでなければソースコードを書いた発注先会社の個人が「著作者」となります。
SES契約の場合
SESも請負と同じ扱いです。SESならば会社との間に支配・従属関係があるだろう（指揮命令できるだろう）と思われるかもしれませんが、指揮命令すれば違法（偽装請負）です（偽装請負については今後別記事で紹介します）。
派遣社員の場合
一般労働者派遣の派遣社員にソースコード作成を命令した場合は、発注元会社の職務著作になりえるので、発注元会社が「著作者」となりえます。
開発委託契約と著作権／著作者人格権
発注元会社は発注先会社に開発委託費を払いますが、それでも「著作権」の譲渡を自動的に受けられるわけではありません。譲渡されるべき「著作権」は契約書に明記する必要があります。
また、何度も言いますが「著作者人格権」はどんなにお金を積んでも譲渡できません。上記のルールで決まった「著作者」が保持したままになります。発注元会社がソースコードの「著作者」になれない場合、契約書に「発注先会社は著作者人格権を行使しないものとする」という条項を含める必要があります。著作人格権は「放棄」させることができないため代わりに「行使しない」ことを約束させる…というのは怪しい方法に見えますが、社会通念上有効な契約とみなされます。
まとめ
PMとして協力会社に発注するとき、フリーランスや法人化して案件を受注するとき、契約書にソースコード特有の観点が盛り込まれているか、確認してみましょう。
実際に揉めた事例を見聞きしたことがありましたら、ぜひコメントで教えてください。
おまけ： 「コードを書けないエンジニア」はソースコードの著作者になれる？
冒頭で「コードを書くエンジニア」の責務と言いましたが、日本には「コードを書かないエンジニア」という概念も存在します。ちょうど今年、「コードを書けないエンジニア（ザキ feat.lemon）」というダイレクトな曲名の自主制作ラップソングが公開されました。ぜひ聴いてみてください。
この歌を初めて聴いたとき、「コードを書けないエンジニア」が今後どうなりたいのかを知りたくなりました。思い切って作者に質問すると、驚くべき回答が返ってきました。
- 別にコードを書けるようになりたいわけではない、だから書く練習もしない
- 引け目を感じるが、エンジニアを名乗るのことはやめない
- 調整役をやり続けるか、コンサルへの転職がゴール
結論。「コードを書けないエンジニア」は、コードを書けるようにならないので、ソースコードの著作者になることはありませんね。
なお、私の本心では「コード書けないエンジニア」のことを決して「エンジニア」だと認めたくはありません…。しかし、彼らを「特殊なエンジニア」と呼んで「特殊なルール」で扱うように心がけることはできそうです。
おまけ： ソースコード流出事故と著作権法および契約上の責任
今年も残念ながら、ソースコードの流出事故がニュースになりましたね。
2017年12月、「T-Connect」ウェブサイト開発委託先企業が、取り扱い規則に反し、ソースコードの一部を誤って公開設定のままGitHubアカウントへアップロードした
みなさんはこの発表内容を見てどう思いますか？ 私は違和感がありました。少しプロジェクトの状況を想像してみてください。
- 「開発委託先企業」（１次請け）や再委託先（2次受け以下）を含めて、延べ数十人のエンジニアやデザイナー（メンバー）が関わっている
- 各メンバーは、それぞれのGitHubアカウントを使用し、リポジトリ上のソースコードを閲覧/改修し、プルリクを出している
- 他のリポジトリも含めて、Organizationで一括管理されている
仮にこの状況だとして、リポジトリが公開設定（public）になっていることに、延べ数十人が5年近くのあいだ気付かない？？ そんなことが有り得るのでしょうか。私もエンジニアとして数々のプロジェクトに関わってきましたが、このストーリーでは到底理解・納得ができません。
想像ですが、おそらく、
- １次請けの「コードを書けないエンジニア」がリポジトリを管理していた
- ２次請け以降のエンジニア・デザイナーの一部にリポジトリへのアクセス権が付与されていなかった（メンバー管理不能な多重請負状態だった）
- リポジトリにアクセスできないメンバーの間で、ソースコードをまるごと圧縮して共有するようなことが常態化していた
- バージョン管理のしづらさに耐えかねた１〜３名程度の少数メンバーが、ソースコードを別のオレオレGitHubリポジトリに上げて
自主管理していた - そのオレオレリポジトリは誤って（最初から）公開設定になっていた
…ではないでしょか。このストーリーならなんとか理解できます。
さて、すでに書いたように、ソースコードに付随して譲渡されるべき著作権は契約書に明記しなくてはなりません。契約書も想像ですが、「発注先会社は著作者人格権を行使しないものとする」と記載があったと仮定しましょう。その場合、
発注先会社が契約に反して著作人格権の一つである「公表権」を使ってしまった
こちらが争点になるのではないでしょうか。記載がなかった場合は、民法の「善管注意義務違反」ですかね。いずれにしても、エンジニアとしては決して流出事故など起こさないように気をつけたいものです。