エンジニアHubPowered by エン転職

若手Webエンジニアのための情報メディア

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

法律トラブルを回避するための、エンジニアが留意すべき法律知識とは、一体どのようなものでしょうか。エンジニアの経験を持つIT弁護士・河瀬季(かわせとき)さんに話をうかがいました。

昨今、“無断転載”の線引きや引用のあり方など、インターネットと著作権の関わり、ひいては法律との関わりが注目される機会が増えてきました。そんな中、エンジニアとして働く人々はいかに法律と向き合っていけばいいのでしょうか。

企業に在籍しているエンジニアの場合、社内に法務担当者がいるかもしれませんが、法律と無関係ではいられません。使用するツールやサービスの高機能化に伴い、無償で多くのコードに触れる機会が増えています。また、自作サービスのフレームワークなどに、オープンソースソフトウェア(OSS)を利用したい方もいるでしょう。

しかし、OSSにも著作権の問題はついてまわります。個人開発の場合でもサービスのリリース時に法律の知識を正しく知っておかないと、サービスの公開停止を余儀なくされたり、損害賠償を請求されたりするケースにもつながりかねません。

もしあなたがフリーランスのエンジニアなら、受託開発契約書で確認する著作権上のポイントを押さえておけば、自分に不利な契約を避けられるでしょう。

法律トラブルを回避するための、エンジニアが留意すべき法律知識とは、一体どのようなものでしょうか。エンジニアの経験を持つIT弁護士・河瀬季(かわせとき)さんに話をうかがいました。

f:id:blog-media:20170726143021j:plain

モノリス法律事務所 弁護士・河瀬季(かわせ・とき/ @tokikawase/写真左)
元エンジニアの弁護士。大学入学直後よりエンジニア、ITライターとして働く。ITベンチャーの企業法務等を担当したのち、モノリス法律事務所を設立。システム開発など、IT企業の日常的業務の中で生じる法律問題、著作権や特許などの知的財産権分野のほか、投資や小規模M&Aなどベンチャー企業において特徴的に発生する法律問題などが得意分野。
聞き手:池田健人(いけだ・けんと/@ikenyal/写真右)
2011年に某Web系IT企業に入社したWebエンジニア。サーバサイドからフロントエンドを担当。そのためOSSを利用することも多く、法律知識も意識しながら業務を行う。エンジニアが関わる法律を、法律の専門家である弁護士がどのように解釈をしているのかに興味を持っている。

エンジニアが法律知識を知らないとどう困るのか?

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

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

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

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

著作権編:著作権関連の最大のリスクは、差止請求権

池田
まずは著作権についてうかがいます。ソースコードのコピーについて著作権の観点ではどんなリスクがあるのでしょうか?
河瀬
著作権で認識しておきたいのは、ソースの作者が「これは著作権侵害だ」と判断した場合、差止請求権を行使し、公開を停止されるリスクがあることです。

仮にソースコードをコピーして制作したアプリで1,000万円儲けているとします。そのソースコードの作者は、もしかしたら「1,000万円儲かっているそのアプリを停止しないでおいてあげるから、その代わり700万円払ってほしい」と圧力をかけてくるかもしれません。世間の相場と無関係な金額を要求されるリスクとなってしまうのです。

ソースコードを「参考にする」と「パクる」の境界線はどこか

池田
ソースコードの著作権は、法律でどう解釈されるのか気になります。「参考にする(合法)」のと、「パクる(違法)」の違いはどこにあるのでしょうか?
河瀬
著作権の基本的な思想として、「アイデア・表現二分論」という話があります。要約すると、著作物を「アイデア」と「表現」に二分した場合、著作権で保護されるのは表現の部分だけということです。

具体的には、あるアプリケーションの雰囲気、UX、レイアウトといった部分は実は表現ではなくアイデアなので、真似してもいいんです。むしろそれを禁止されてしまうと何もできなくなってしまいます。

その点を踏まえた上でソースコードに関して言うと、コピペ以外はほぼパクリではないと言ってしまってもいいと思います。

池田
ソースは丸写しでも、変数名を変えれば「アイデア」になるのですか?
河瀬
いえ、それでは「パクリ」と解釈されるでしょう。しかし、多少加工することで、加工前のソースコードが持っていた「表現」は、加工後のソースコードにおいて、「アイデア」のレベルに過ぎなくなり、結局、違法(パクリ)と断定できないケースが多いことも事実です。

プログラム言語やアルゴリズムは著作権保護の対象とはなっていませんが、プログラム言語によって作られたソースコードは対象ですので、ほぼコピペした状態で「自分の制作物だ」として公開するのは危険です。

池田
制作時のイメージを仮組みするために、一時的に他者が公開しているソースコードや画像を借りる場合もあると思います。うっかりそのまま自分の制作物として公開しないよう、注意が必要ですね。

コラム:IT分野での特許権は機能しづらい

池田
ITシステム全体の話となると、著作権ではなく特許権の問題になるのでしょうか?
河瀬
システム周りに関しては、特許はあまり「強い権利」とは言いにくいところがあります。

そもそも特許というのは、典型的には青色発光ダイオード(LED)のような製品のためのもの。「人間が決めた決まりごと」や「アルゴリズム」を守るためのものではなく、「自然法則を利用したいわゆる『発明』」を守るためのものです。

ITシステムでも特許権は使われてはいますが、サーバーの構成を多少変えれば権利侵害ではなくなってしまうケースもあるなど、きちんと戦略を立てて特許出願を行わないと、法的な縛りが弱くなってしまう傾向があります。

ですので、特許取得済みだから絶対に真似されない、もし真似されても裁判で絶対勝てるという考えは危険です。

池田
ITの分野では特許権自体が強くなく、あまり機能しないという認識なんですね。

他人のブログで自分が書いたソースコードを紹介されたら著作権違反?

池田
ソースそのもののコピーではなく、他人が書いたソースコードを自分のブログ上でコピペして紹介するだけなら、問題はありませんか?
河瀬
著作権法第32条に定められた「引用」に該当していればOKです。

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

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

池田
逆に、自分が引用方法を間違って損害賠償の支払いを求められた場合は、払う義務は発生するのでしょうか。
河瀬
実際に訴訟に至るケースはそこまで多くありません。ただし、クレームが入った場合には誠意をもって謝罪し、記事を消すなどの対応を検討するべきです。

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

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

OSSでも、ルールを確認し正しく利用しよう

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

活用範囲が広い! MITライセンスとは

OSSには数多くのライセンスが存在します。MITライセンスは無償で扱え、かつコピーや再配布のほか、改変や商用利用も可能なソフトウェアライセンス。MITライセンスのソフトウェア利用時は、許諾表示をソースコード内に入れ込むことが義務づけられています。

MITライセンスを1行1行読んでいく | プログラミング | POSTD

条件を組み合わせて作品を発信! クリエイティブ・コモンズ・ライセンスとは

Webにおける権利関係を知るなら、「クリエイティブ・コモンズ」も把握しておきたいところ。画像や音声、動画で使われることが多いライセンスシステムです。

クリエイティブ・コモンズは、クリエイティブ・コモンズ・ライセンス(CCライセンス)を提供している国際的非営利組織とそのプロジェクトの総称です。CCライセンスとはインターネット時代のための新しい著作権ルールで、作品を公開する作者が「この条件を守れば私の作品を自由に使って構いません。」という意思表示をするためのツールです。

クリエイティブ・コモンズ・ライセンスとは | クリエイティブ・コモンズ・ジャパン

スクレイピングやAPIも著作権違反になりうる?

池田
ツールについてもうかがいます。もし、勝手にスクレイピングをしてアプリを作ったり、アプリがたたいているAPIを突き止めてそれを使う場合はどうでしょう?
河瀬
スクレイピングには、著作権の問題が関わってきます。APIに関しては、基本的には問題はありません。ただし、使用しているAPIを突き止めたアプリにアカウントを作った上で非公式な使い方をすると、アカウント停止になるリスクがあることは認識しておくべきでしょう。

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

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

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

契約書編:一番トラブルが起こりやすいのが受託開発契約

池田
次は契約書関係のトラブルについて聞いていきたいと思います。冒頭では「契約書で合意が不十分だったためにトラブルが起こった」とうかがいましたが、どのような点がトラブルになりやすいのですか?
河瀬
IT関連の契約で一番トラブルが起こりやすいのが受託開発契約です。たとえば「クライアントが思っていたシステムとは違うものができた」「どの時点で費用が発生するのかがあいまいだった」などですね。

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

f:id:blog-media:20170726143025j:plain

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

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

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

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

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

契約書でここだけは見るべきチェックポイント3つ

池田
契約書を読むのが得意な人ばかりではありません。特に注意して読むべき箇所などはあるのでしょうか?
河瀬
契約書を読み進めるときに、特に重要になるポイントは3点です。ご説明しましょう。

1. 成果条件は請負か準委任か

河瀬
1つ目は、どんな形態で報酬が支払われるのか。エンジニア的な言葉で表現すると「成果条件は何か」です。システム開発の成果条件は大きく2種類に分かれます。
  • 物を完成させたらお金がもらえる
  • 頑張って働いたらお金がもらえる

法律用語でいうと、前者が請負、後者が準委任です。

請負の場合、注意していただきたいのは「検収」です。要件が「物を完成させること」なのであれば、成果条件は要件充足の有無であるかを確認してください。

ベンダーは約束したものを納品すればいいのであって、クライアントにとってそれが満足いくものか、きちんと使えるかは契約外のことです。もし検収において、「満足できないから成果条件を充足していない」と言われてしまうと、延々と再検収が続くことになってしまいます。

2. 将来的に行うサポート範囲と対価のバランス

河瀬
2つ目は、先ほども述べたとおり将来的に発生する仕事と対価のバランスを考えることです。作業前に高額な報酬をもらえても、その後何年間も要件非充足に対応し続けなければいけない契約だと、見方によっては不利になります。

そのため、報酬は「自分が見積もった期間への対価」だけではなく、契約後に自分がしなければいけないメンテナンス等も考慮に入れた上で対価のバランスを見ましょう。

たとえば、ある程度の修補やカスタマイズが必要になることが最初から分かっているのであれば、システム製作代とは別に保守契約を月額20万といった金額で結び、その金額の範囲内で対応するという方法もあります。

3. お金が支払われる時期はいつか

河瀬
最後は報酬が支払われるタイミングです。クライアントとベンダーの力関係の差が大きい場合、お金が支払われるタイミングが遅いほどベンダー側に不利になります。

たとえばベンダーが報酬を受け取る前だと、クライアントから「システムのこの部分を直さなければお金を払わない」という一種の圧力が効きます。最悪なのは、クライアントが満足しない限り、完成として認めない。かつ、完成しないとお金が振り込まれないという状況です。

このように不利な状況に追い込まれると、これまでにかけた作業量を無駄にしたくないというサンクコスト効果*2が働いて、相手の言いなりにならざるを得なくなるため非常に危険です。

後はクライアントとの継続的な関係性とキャッシュポイントを踏まえた上で契約書を読んでいきます。基本的にはどんな形であれ、なるべく早い段階で確実に入金されるような契約になるよう交渉するのが重要です。

「最悪の最悪があった場合に、この契約関係からどう離脱できるのか?」というシミュレーションをしてから契約を結ぶことが大切です。

契約後に不利な項目が見つかったら書き直すべき?

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

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

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

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

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

裁判では契約書がどう解釈されるの?

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

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

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

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

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

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

おわりに

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

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

f:id:blog-media:20170726143029j:plain

*1:大卒男性(正社員)の平均生涯賃金は2億7千万円。(出典:労働政策研究・研修機構『ユースフル労働統計2016』)

*2:行動の結果発生したコストが、のちの意志決定に影響すること