Footprints

弁護士・伊藤雅浩による仕事・趣味・その他雑多なことを綴るブログ(2005年3月開設)

著作権がないと困るのか

システム開発関係の契約交渉,契約書チェックの際によく論点となるのが著作権の帰属関係。


お金を支払うユーザの側はもちろん,開発するベンダの側も「著作権はうちに帰属させたい」という綱引きをすることがある。しかし,果たして本当に,自己に著作権が帰属していないと困るのかどうか,あまり考えないまま,綱引きをしていることも少なくない。


そういうとき,ベンダ,ユーザに対し,「著作権って絶対に自分のところにないと困りますか?それはなぜですか?」と聞くようにしている。


ここでは,開発したシステムが,プログラムの著作物(著作権法10条1項9号,2条1項10号の2)に該当することを前提に,基本的事項を整理しておく。


著作権者は著作物の「利用」についてコントロールすることができる。言い換えれば,第三者が,著作権者の許諾なくして著作物を利用していれば,その差止を求めたり(同法112条1項),損害賠償を請求したりすることができる(民法709条,著作権法114条)。


だからこそ,ユーザもベンダも,自己に著作権を帰属させたいと考えるわけだが,「利用」とはどのような行為を指すのか,あまり認識されていない。

ユーザの視点


著作権法では,著作物の「利用」と「使用」は区別されている。「利用」とは,上述のとおり,著作権者の許諾なくして行えない行為であり,著作権法21条から28条に列挙された行為をいう。具体的には,システムに関するところでは,複製(21条),公衆送信(ネットを通じた配信,23条1項),翻案(改良・修正等,27条)などである。他方,「使用」とは,著作物の効果を享受する行為で,プログラムであれば,コンピュータ上で実行させる行為であるし,本であれば読む,音楽であれば聴く行為を指す。


以上から明らかなとおり,著作権者でなくとも,プログラムの著作物を「使用」することは,著作権者の許諾なくして行うことができる*1。だから,純粋にユーザとして使用するだけであれば,著作権は自己に帰属していなくても構わない。


もっとも,プログラムは実行するにあたり,メモリにロードされるなどして,「複製」行為が介在する。だから,純粋に「使用」だけで閉じることはないから,著作権者の許諾がなければプログラムの使用も著作権侵害ではないか,ということが指摘されていた。この点については,平成21年の著作権法改正で,著作権の制限行為として,47条の8「電子計算機における著作物の利用に伴う複製」が追加され,「情報処理を円滑かつ効率的に行うために必要と認められる限度」での利用には,著作権の効力が及ばないとされている。


少し脇道にそれたが,結局,著作権がなくとも,ユーザとして使用するだけであれば特に問題ない。


では,第三者に「使用させる」(利用させるではなく)ことは制限されるか。結局,著作権法の枠組みでは「使用」そのものが制限されない以上,第三者に使用させること(複製を伴わないことが前提)にも制限がかからない。つまり,ユーザが,自社の子会社や取引先にシステムを使わせることは可能である(そっくりそのままコピーして渡すことは「利用」行為を伴うことに留意。)。ただし,これはあくまで著作権法に関連する議論であって,実際には,システム開発契約や,サービス利用規約などで,ユーザが第三者に使用させる場合の範囲などを制限することがある。これに反すれば,著作権侵害でなくとも,契約違反にはなる。


次に,「複製」「翻案」ができないとなると,開発機と本番機にインストールしたり,ユーザ社内のエンジニアでメンテナンス(機能追加等)をする行為ができなくなるのではないかという問題がある。この点については,同じく著作権の制限規定である47条の3(プログラムの著作物の複製物の所有者による複製等)にて,「自ら・・必要と認められる限度において・・複製又は翻案・・をすることができる。」とされているので,自己利用のためであれば問題ない。これを第三者に販売したりすることができないのは明らかだが。


ここも厳密に考えると,「所有者は・・複製又は翻案をすることができる」にとどまるため,ユーザ企業のシステム子会社は所有者ではないから,メンテナンスさせることはできないのではないか,という問題も考えられるところである。しかし,委託の形態にもよるが,子会社の従業員にメンテナンスさせたというような場合には,実質的に「所有者」の行為と考えるべきだろう。

ベンダの視点


ベンダから見れば,ユーザに著作権を譲渡してしまえば*2,それ以降,複製,翻案がユーザの許諾なくしてできなくなるから,別の顧客にそれを提供したり,勝手にパッケージソフトとして販売することはできなくなってしまう。


当然,ベンダとしては,一度作ったプログラムは使いまわすことでコスト,納期の競争力を高めたいところであるから,著作権は留保させておきたいところである。

ふたたびユーザの視点


そうすると,子会社に使用させたり,メンテナンスなどをすることも,著作権法上は特に制限されないことになる。よって,ユーザとして必要な行為のほとんどは特に著作権を譲り受けなくとも可能であるから,ユーザが「著作権をよこせ」という必要性がないように思われる。


それでもなお,ユーザが著作権の帰属にこだわる理由としては2つ考えられる。


ひとつは,「お金を払っているんだから,とにかくウチのものだ。ウチがお金を払って作ったシステムを,勝手にヨソで安くばらまかれては困る」という現実的な理由。この考え方がこれまで一般的であったために,これまでのシステム開発は,各社各様のシステムを,技術的には再利用できるものであっても,すべてスクラッチから開発するという非効率なことが行われてきた。


ユーザとしては,「自分がお金を払ったものを流用させたくない」と考えれば,その裏返しとして「このベンダが過去に開発したものを流用してもらって安く・短期に開発する」ということも期待できないわけで,結局のところ,高コスト・長納期のシステム開発が至る所で行われ,その結果,失敗プロジェクトが増える原因ともなった。


ベンダに著作権を留保した上で,そのベンダが,第三者向けの開発の際に再利用した場合には,元のユーザと,レベニュー・シェアをするということが実現できれば,元のユーザ,ベンダ,新しいユーザの三者が得するという構造にもなるはず。パッケージソフトクラウド型サービス(SaaS)の思想はここにあるのだが,今でもスクラッチ開発&著作権はユーザ帰属というケースは多い。


もうひとつの理由は,ベンダが破産してしまったり,著作権を第三者に譲渡してしまうことの対策として著作権の譲渡を求める,というものである。


確かに,ベンダがシステムの著作権保有したまま破産すると,ベンダとの契約が解除されたりしてしまう可能性があるし(破産法53条1項),ベンダが事業譲渡その他の理由により,著作権を譲渡してしまう可能性もある。その場合,新著作権者(譲受人)のもとでもシステムを使い続けることができるのか,という不安がある。


この点については,上述のとおり,通常のユーザとして使用をする限りにおいては「著作権法的には」ほとんど支障がない。「著作権法的」に限定しなければ,メンテナンスしていたエンジニアが捕まらなくなったりして,実務上困るということは十分考えられるが,これはユーザ側に著作権を移転させていたとしても同様の問題は起こる。このリスクをヘッジする一つの方法としては,エスクローサービスを利用することだが,この点については深く立ち入らない*3


しかし,やはりユーザとしては,譲受人との間でゴチャゴチャとしたやり取りを避けるために,「当社は著作権者(少なくとも共有著作権者)です」としておいたほうが安心である。その際に注意しなければならないのは,「著作権」というものは形のない,目に見えないものであるために,いったんベンダからユーザに譲渡されたとしても,ベンダはいつでも第三者に二重譲渡してしまう危険があるという点である(法的には対抗問題という。)。きちんと譲渡が行われたということを第三者に対抗できるようにするためには,著作権の移転登録(著作権法77条1号)をしなければならない。ただし,この著作権の登録は実際のところ,ほとんど行われていない。


プログラム著作物については,特別規定があり,「プログラムの著作物に係る登録の特例に関する法律」に基づいてSOFTICが「指定登録機関」として登録事務を実施している(他の機関はない。)*4。以前は,マイクロフィッシュソースコードを焼いて提出する必要があり,相当の費用を要したが,本年6月からはCD-R,DVD-Rでも申請ができるようになった。


****

以上の議論を踏まえて,契約条項でどう書くかという点についても触れようと思ったが,その点は,また別途の機会に。

*1:例外として,違法コピーのプログラムを,違法コピーだと知った上で,業務上使用する行為は,「侵害する行為とみなす」とされている。同法113条2項

*2:よく契約書に「成果物に含まれる著作権は,ユーザに帰属する」とだけ書いてあるものをよく見かけるが,実際のプログラミング作業はベンダがやっている以上,原始的にはベンダに帰属し,それが引渡しなどのタイミングでユーザに移転すると解釈すべきだろう。

*3:破産手続申立などの一定条件が満たされたことをトリガーとして,ソースコード,ドキュメント等をエスクローエージェントから開示を受けられる,という手続をいうが,問題は,ソースコードなどを開示されても,結局,「人」が捕まらないとどうしようもなかったりするという点である。

*4:http://www.softic.or.jp/touroku/index.html