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

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

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

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

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

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

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

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

モノリス法律事務所 弁護士・河瀬季(かわせ・とき/ @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関連の契約で一番トラブルが起こりやすいのが受託開発契約です。たとえば「クライアントが思っていたシステムとは違うものができた」「どの時点で費用が発生するのかがあいまいだった」などですね。

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

1

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

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

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

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

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

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

池田
契約書を読むのが得意な人ばかりではありません。特に注意して読むべき箇所などはあるのでしょうか?
エンジニアHubに会員登録すると
続きをお読みいただけます(無料)。
登録のメリット
  • すべての過去記事を読める
  • 過去のウェビナー動画を
    視聴できる
  • 企業やエージェントから
    スカウトが届く