エンジニアが知っておきたい法知識。ソースコード著作権＆開発契約を元エンジニア弁護士に聞く！

池田

すべてのエンジニアが法律知識を持っているわけではありません。法律知識を知らないと、どんな問題が起きるのでしょうか？

河瀬

関わっている案件で法律関係のトラブルが起きたときに、所属する会社や個人が大きな損害を被るリスクがあります。一例ですが、システム開発案件でクライアントとベンダーの合意が不十分だったために、納品後の売り上げが一瞬で吹き飛んでしまうようなリスクも考えられます。

裁判になり、会社の損害額が数千万円に上る場合もざらですし、私が担当した案件では、5,000万円の損害が出たこともありました。サラリーマンの一生の稼ぎ¹のうち、約5分の1がたった1回の失敗で消えると考えると、その甚大さが想像できるのではないでしょうか。フリーランスエンジニアの方が、1,000万円もの売り上げを回収できなくなった事例もありました。

また、著作権を侵害してしまった場合も大損害になることがあります。たとえば、自分で制作した有料アプリが著作権法に違反しているとして配信停止を命じられた場合は、停止した次の日から売り上げが立たないことになってしまいます。

エンジニアが特に気をつけたいのは2点。著作権の問題と、受託開発時の契約書関連の問題です。

池田

ソースそのもののコピーではなく、他人が書いたソースコードを自分のブログ上でコピペして紹介するだけなら、問題はありませんか？

河瀬

著作権法第32条に定められた「引用」に該当していればOKです。

逆に、自分が公開した著作物が引用の範囲を超え真似されてしまった場合は、管理者に直接注意するべきです。相手が大手企業だとしても、個人で差止請求をすることができます。ただ、ある程度大きなメディアに掲載された場合、多くの人が閲覧してくれる、という側面もあるでしょう。

その場合、「ただ記事の差し止めを要求する」、だけでなく、引用要件を満たした上で、個人のブログやWebサイトに誘導してもらう方が良いかもしれませんね。

池田

逆に、自分が引用方法を間違って損害賠償の支払いを求められた場合は、払う義務は発生するのでしょうか。

河瀬

実際に訴訟に至るケースはそこまで多くありません。ただし、クレームが入った場合には誠意をもって謝罪し、記事を消すなどの対応を検討するべきです。

損害賠償金に関しては、本当に支払う必要があるのか弁護士に相談してみてください。なぜなら、差止請求権は故意過失がなくても発生しますが、損害賠償の支払い義務は故意か過失かの認定が必要だからです。

まとめると、著作権の一番強い効果は「差止請求権」。ブログの場合は差し止められてはいけない部分では引用の要件を守る。サービスの場合はサーバサイドなど、入れ替えが極めて困難なところでは「パクり」とならないように留意する、ということです。

河瀬

無償で公開されているOSSにも、利用方法は定められています。OSSの公式ページではライセンスについても触れているので、きちんと読んでからルール通りに使いましょう。

池田

ツールについてもうかがいます。もし、勝手にスクレイピングをしてアプリを作ったり、アプリがたたいているAPIを突き止めてそれを使う場合はどうでしょう？

河瀬

スクレイピングには、著作権の問題が関わってきます。APIに関しては、基本的には問題はありません。ただし、使用しているAPIを突き止めたアプリにアカウントを作った上で非公式な使い方をすると、アカウント停止になるリスクがあることは認識しておくべきでしょう。

どこまでやっていいのかを明確に線引きすることは困難です。しかし、非公式な使い方をしている以上、運用には常にリスクがつきまとうものです。

以前、Twitterのツイート数取得ができる公式APIの提供が廃止されましたが、第三者が代用のサービスを提供しています。Twitter社はコメントをしていないようですが、後から停止を要求される可能性もあるでしょう。

池田

APIの非公式利用や特許の話など、法整備がITサービスの進歩に追いついていない部分も多くあるようですね。

池田

次は契約書関係のトラブルについて聞いていきたいと思います。冒頭では「契約書で合意が不十分だったためにトラブルが起こった」とうかがいましたが、どのような点がトラブルになりやすいのですか？

河瀬

IT関連の契約で一番トラブルが起こりやすいのが受託開発契約です。たとえば「クライアントが思っていたシステムとは違うものができた」「どの時点で費用が発生するのかがあいまいだった」などですね。

ですから契約書以前に、明確に要件定義をしておくことが大前提です。その上で、どんなプロダクトをいくらで作るのか、といった合意の内容を文書化することが重要です。契約書は、契約の時点で双方の合意が取れていた客観的な証拠として、裁判になった際の判断材料になります。

また、納品後であっても瑕疵担保責任（かしたんぽせきにん）の問題があります。これは、納品されたものが、本来あるべき機能・品質・性能・状態を備えていない場合、受託者が委託者に対して負う責任のことです。

システム開発における「瑕疵」とは具体的にどのようなものか、というのは、過去にさまざまな裁判例で争われているテーマです。自分が結ぼうとしている契約における「瑕疵」とは具体的にはどのような意味なのかは、しっかりと把握しておくべきです。

たとえば、仕様書との不一致に限定されるのか、論理的誤りを含むのか。「瑕疵（仕様書との不一致、論理的誤りまたは通常有すべき機能、品質、性能を欠いている状態をいう。以下同じ）」といったように、「瑕疵」をある程度具体的に定義しておくことは、後々の紛争を防ぐために重要かと思います。

ただ、受託者から見て、「瑕疵の定義が広い場合には必ず契約書を修正させなければならない」ということではないと思います。結局は、「将来的に発生する仕事」と「対価」のバランスでしかないからです。

「1回で検収が終わり、その後、瑕疵を修補する業務は発生し得ない」という前提でバランスを考えるのではなく、たとえば「瑕疵」が指し示す範囲が広く、修補が必須になる可能性が高いのであれば、その工数も見積もった上で「対価」を設定し、バランスをとればいいのです。そうした「合理的な判断」のために、契約書をよく読む必要がある、というだけです。

池田

契約書を読むのが得意な人ばかりではありません。特に注意して読むべき箇所などはあるのでしょうか？

池田

契約でどうしても弱い立場になりやすい個人やスタートアップが注意することはありますか？

河瀬

将来的に発生する仕事と対価のバランスを考えましょう。契約書では表面的に見える仕事量と対価のバランスは示されていても、潜在的な仕事量と対価のバランスまで気にしないケースが多々あります。そのため、立場の弱い側が実際は不利な契約であることに気が付かないままサインしてしまいます。

たとえば、「納品したシステムがOSその他のミドルウェアとの相性で正常動作しなくなった場合のカスタマイズを納品後2年間無償で行わなければならなくなる」といった意味の文言に気づかず、当該条項を修正することなく、そのまま契約してしまうケースが典型的な例です。

ただし、契約後に不利な条項があった場合でも、ベンダー側としては、必ずしもその条項を修正する交渉をする必要性はありません。作業量が増えると予測されるなら金額を上げてもらう、もしくは保守契約も同時に結び、その保守契約上で処理する、とすればいいわけです。

要は、作業量とお金のバランスの問題であり、「合理的な判断を行えばいい」ということにつきます。もともとエンジニアは合理的な思考が得意な人種のはずですから。ただし、契約書を読まないと、合理的判断に必要な「契約の条件」が分からない。だからこそ、契約書をよく読むことが重要なのです。

契約書を読む、交渉を行う、といった行為は「法律的に自分に有利な文言だらけの契約」を締結するための行為ではありません。ビジネス上の利益を確保するための契約、という大きな目的を忘れないようにしてください。

池田

もしトラブルが起きて裁判になった場合、どのようになるのですか？

河瀬

裁判ではそのシステムのプログラムが実際に動いているかどうかが重要視される傾向があります。請負型の契約の場合「システムは完成しているか」、「完成しているが、瑕疵があるのではないか」という二段階の判断になるのが一般的です。

つまり、重大なバグがある場合でも、そのシステムが現に動いていれば「完成」はしている。あとは「瑕疵」が論点である、と判断されやすいというわけです。

また、もう一つ、裁判所の基本的な発想として「（初期の）契約が果たされたか」という場面と、「追加発注の契約があったかどうか」という場面では、「契約成立」の認められやすさが異なる、という傾向があります。初期の契約に関しては、ベンダー側に対して厳しく、契約成立が認められにくい傾向があります。

たとえば、採用通知をベンダーが受け取った（＝初期の契約が果たされた）にもかかわらず、裁判で契約不成立とされたケースも現実に存在します。そのため、そもそも双方に契約関係があるかどうかという段階では、ベンダー側は「必ず契約書に押印を貰わなければいけない」というように、慎重に動く必要があります。

一方、追加発注の段階では、追加見積もりに対する書面上の明示的な合意がなくても支払い義務を認めた判例があります。追加発注の段階では、裁判所の見方は、初期の契約成立の場面より緩まるわけです。

ただ、そうはいっても、こうした裁判所の「傾向」を当てにしてしまうのは危険です。可能な限り、追加見積もりでも再度契約書を作って契約を結んでおきましょう。

河瀬

トラブルの内容によっては、エンジニアが所属している企業はもちろん、直接関わりのない人にまで影響が及ぶ可能性が大いにあります。

エンジニアも法律知識を正しく理解するよう努め、要らぬトラブルを避けられるよう、「著作権」「契約書」の2点を心に留めておいていただけると嬉しいです。