外注したアプリの著作権は誰のもの？発注前に確認すること

一年前に作ってもらった社内のアプリに、項目をひとつ足したい。頼んだ相手とは、もう連絡がつかない。ソースコードは手元にある。別の技術者に渡して直してもらおうとしたら、その人から「これ、勝手に触ってよいものですか」と聞かれた。

そこで初めて、契約書らしきものを探すことになる。出てきたのは見積書とメールのやり取りだけ。「納品」とは書いてあるが、権利という言葉はどこにも見当たらない。ここで手が止まってしまう会社は、珍しくない。

先に結論を書く。「納品された」ことと「権利が移った」ことは別だ。書いていなければ、作った側に残るのが原則とされている。動くものを受け取ったことと、それを自由に扱えることは、別々に決まる。決まっていないなら、決まっていない状態のまま置かれているだけだ。

納品された、では権利は動かない

お金を払って、動くものを受け取った。だから当然こちらのものだ、という感覚はよく分かる。ただプログラムは、机や椅子とは扱いが違う。物として受け取ることと、その中身を書き換えたり別の用途に回したりしてよいこととが、切り離されている。

一般に、プログラムの権利はまず作った側に生まれ、契約で移すと書いて初めて相手に移るとされている。つまり何も書かなければ、作った側に残る。誰かが意地悪をしてそうなるのではなく、決めていないから既定の状態のままになる、というだけの話だ。

そして、うまく回っている間はこの話が表に出てこない。困るのは、頼んだ相手と連絡が取れなくなったとき、社内の担当者が辞めたとき、別の会社に引き継ぎたくなったときだ。出てくるのはいつも例外のときで、そのときには決め直す相手がもういない。

譲るのか、使ってよいと言われているだけなのか

書面がある場合でも、中身は大きく二つに分かれる。ひとつは譲渡で、権利そのものが依頼した側に移る。もうひとつは利用の許諾で、権利は作った側に残したまま、使ってよいという許可だけが出ている状態だ。

やっかいなのは、どちらも日本語では「納品します」「お渡しします」と書かれてしまうことだ。見た目の文面では区別がつかないし、書いた側にも区別する意識がないことがある。確かめ方そのものは難しくない。専門用語を使う必要もなく、ひとこと聞けば足りる。

「このプログラムを、別の技術者に渡して改修してもらっても構いませんか」

この一文には、譲渡なのか許諾なのか、許諾ならどこまで許されているのか、がまとめて入っている。はい、と返ってきたら、その返事をメールでよいので文字で残しておいてください。口頭のやり取りは、半年後には双方の記憶が食い違う。残っていないものは、後から誰も確かめられない。

作った側の部品まで、譲られるわけではない

ここで誤解が生まれやすい点がひとつある。開発者は、以前から書きためた汎用の部品を持っていることが多い。表を並べる仕組み、ログインまわり、帳票を組み立てる処理。今回のために書いた部分と、前から持っていた部分が、同じソースの中に混ざっている。

既存の部品まで丸ごと譲ってしまうと、開発者は次の仕事で自分の部品が使えなくなる。だから多くの場合、今回のために作った部分は譲り、もとから持っている部品は譲らずに使う許可を出す、という形になる。世の中に公開されている無償の部品を組み込んでいる場合も、事情は似ている。

では困るのかというと、実務ではそうでもない。要るのは所有そのものではなく、あとから止められないことだ。譲られない部分についても、期限なし・追加費用なし・別の技術者に引き継ぐ場合も含めて使い続けられる、と書いてあれば、直せなくなる事態は起きない。ここも一行で確かめられる。

権利があっても、手元に無ければ直せない

権利の話が片付いても、それだけでは改修できない。要るのは動いている状態のものではなく、人が読める形のソースコード一式だ。ここが抜けていると、権利は自分にあるのに誰も手が出せない、という妙な状態になる。

受け取る形は、着手の前に決めておいてください。当方の場合は、ソース一式に加えて、データを取り出しておく手順と、管理者向けの操作手順を添えてお渡ししている。ソースの置き場ごと依頼者さまの側へ移す形にしていて、渡したあとに当方の手元で抱え続けることはしない。

もう一つ抜けやすいのがデータだ。プログラムと、その中に貯まった業務のデータは、別のものとして扱われる。名簿も日々の記録も当然自分たちのものだと思っていたら、書面のどこにも書かれていなかった、ということがある。プログラム・データ・手順書の三つで確かめておくと漏れにくい。

事例として載せてよいかは、別に決める

権利とは別に、もうひとつ決めておくとよいことがある。作ったものを、開発者が実績として公開してよいかどうかだ。社名を出すのか、画面の写真を出すのか、匿名で業種だけにするのか、一切出さないのか。

開発者の側からすると、実績が見えることは次の仕事につながる。依頼した側からすると、社内の管理のやり方が外から見えるのは避けたいこともある。どちらが正しいという話ではないので、着手の前に一行で決めておけばいい。言わなければ載せない、を既定にしておくとお互いに気が楽です。

逆向きの線引きも、同じ考え方で引ける。当方は、他社のサービス画面をそのまま複製してほしい、というご依頼はお受けしていない。自分たちの権利を大事にするなら、他所の権利にも同じ扱いをしておくほうが筋が通る。

発注の前に、一行ずつ答えをもらう

ここまでを、発注の前に確かめる形に並べ替えておく。難しい言い回しは要らないし、分厚い契約書を用意する必要もない。項目を書き出して、一行ずつ答えをもらう。それだけで、あとから困る場面はかなり減らせます。

小さな依頼でも考え方は変わらない。1画面だけのツールでも、あとから別の人が手を入れられる状態でお渡ししている。規模が小さいほど書面が省かれやすいので、むしろ短く一行だけ残しておくとよいと思う。

最後にひとつ。ここに書いたのは、発注の前に自分で確かめられる項目であって、法律の解説ではない。契約書の文言をどう書くか、個々の条文がどう解釈されるかは、弁護士など専門家にご確認ください。当方は作る側であって、法律上の判断をする立場にはない。

---

当方は元金融系のシステムエンジニアで、Excel・紙で回している業務を、月額0円の買い切りWebアプリにする仕事をココナラで請けている。お渡しするのはソースコード一式と手順書で、あとから別の技術者に引き継いでいただいて構いません。まだ何を作るか決まっていない段階でも構いませんので、ココナラのメッセージからご相談ください。