Photo by History of the Book / UvA-Special Collections Amsterdam
こんにちは。テクニカル・ライターの可知(@y_catch)です。paiza開発日誌のお手伝いをすることになりました。どうぞ、よろしくお願いします。
普段は、IT製品や技術の紹介記事や、関連情報の解説記事などを書いております。たとえば、オープンソースライセンスや著作権の解説といったものを公開しております。
さて、今回は、ソフトウェア開発におけるパクリ問題の基本的なポイントを整理してみたいと思います。東京オリンピックの開催にからんで、そのロゴデザインのパクリ疑惑に注目を集めました。ソフトウェア開発は、グラフィックデザインとは違う分野ですが、知的財産ビジネスという意味では、共通するところもあります。
ソフトウェア開発に関わる皆さんにとっても、何がパクリで、何がパクリでないのか、どんなふうにしたらパクリ／パクられないのか、といったあたりは大変興味があるんじゃないかと思います。
そこで、このような問題の基本的なところを、分かりやすくまとめていきます。
■パクリとは何か。なぜ、パクリはいけないのか
そもそも「パクリ」とは何でしょうか？ まずは、ここから再確認してみましょう。
本来「パクる」とは、「盗む」「犯人を捕まえる」という意味の俗語でしたが、それが転じて、アイデアやデザインなどを無断で「真似する」「流用する」といった意味でも使われるようになりました([参考]ぱくり - Wikipedia)。東京オリンピックのロゴが「パクった」と言えば、他のロゴデザインを無断で真似したということですよね。この記事でも、このような知的財産の無断流用の意味で「パクる」という言葉を使っています。
では、なぜパクるのは、ダメなんでしょうか。これには、2つの理由があります。
ひとつは、ロゴデザインなどの知的財産が、その利用を許可したり制限したりできる権利を備えているためです。その権利のおよぶ範囲では、権利者の許可なく勝手に利用できません。この権利は、著作権や商標権・特許権・意匠権というように、いくつかの種類があり、それぞれの権利の詳細が法律で定められています。また、グラフィックデザインなのか、音楽なのか、文章なのかというように、その種類に寄っても、権利の内容が変わってきます。さらに、不正競争防止法などの法律や、個別の開発契約によって制限される場合もあります。
つまり、パクリは、法律違反の可能性があるということですね。
もうひとつの理由は、パクるという行為が、周囲から白い目で見られるからです。グラフィックや音楽・文章といった、知的財産を生み出す技芸はゼロから何かを生み出すクリエイティブな行為です。それに対して、無断で真似する行為は、アリものを流用しているだけなので、ある種のウソと見なされて、軽蔑すべき行為となるのだと思います。デザイナーやミュージシャンといった同業者から軽蔑される場合もあるでしょうし、同業者の間では問題なくても、一般的な社会通念によって拒絶される場合もあるでしょう。
つまり、法律による禁止ではなく「モラル」による制限です。
このように「パクリ」は、法律などのルールと、社会によるモラルによって禁じられているのです。
■パクリは、どこまでダメなのか
Photo by Breville USA
ただし、パクリといっても、無制限に真似を禁じていません。
たとえば、イラストに、ピンクのハートマークを描いたら、それはパクリでしょうか？
いえ、すでに共通のシンボルとして、多くの人々が自由に使えるようになっていますよね。グラフィックや音楽・文章といった知的財産は、誰でも自由に利用できる共通の土台によって成り立っています。そこに新たな作品が加わることで、その文化がさらに豊かなものになっていきます。
そのため、著作権や商標権・特許権は、たくさんの限界が設けられています。たとえば、著作権では、文章であれば、作者の死後50年まで保持できるとされています(期間は、作品の種類や国によって異なります)。
モラルによる制限も、インスパイアされたというレベルであれば、問題視されない場合が数多くあります。映画やマンガなどで、構図やモチーフを尊敬を込めて流用することはよくありますよ。たとえば、1977年に公開されたアメリカ映画「スターウォーズ」(エピソードIV/新たなる希望)は、日本映画「隠し砦の三悪人」に、プロットやキャラクター・画面構成などに似ているところが多数あります([参考]隠し砦の三悪人 - Wikipedia )。スターウォーズの監督であるジョージ・ルーカス自身が、「隠し砦の三悪人」から着想を得たと発言しているそうです。
もちろん、著作物のように誰かが権利を持つ場合、丸パクリするのはダメですが、ルールによる制限も、モラルによる制限も、ただ真似を禁止するのではなく、バランスを取ることが重要だということです。
■ソフトウェア開発で、パクリが禁じられている範囲は？
それでは、いよいよソフトウェア開発のパクリについて考えてみましょう。
ソフトウェアは、次のような数々の要素によって構成されています。
では、個々の要素の利用は、どのように保護されるのでしょうか。
◆プログラム
プログラムは、著作権法という法律で守られている著作物です。著作物とは「思想又は感情を創作的に表現したものであって、文芸、学術、美術又は音楽の範囲に属するものをいう」(著作権法 第二条 一)とされています。例示のなかにプログラムが入っていませんが、著作権法の別のところで、プログラムも著作物だと例示されています。
ここでのポイントは、著作物とは"思想又は感情を創作的に表現したもの"という点です。簡単にいうと、オリジナリティが重要だということです。そのため、誰が書いても同じになる、Hello Worldのような短いプログラムは、著作物と見なされない可能性があります。
ここでいうプログラムは、コンピュータの動作の手順を指示する、いわゆる「コード」のことです。ただし、プログラミング言語の文法、アルゴリズム、APIやプロトコルは、著作権の対象外とされています。これらを著作物としてしまうと、すべてのプログラムが、文法やアルゴリズムなどを真似したことになってしまうからです。
◆データ
データの集合体であるデータベースは、著作物です。著作権法ではデータベースのことを「論文、数値、図形その他の情報の集合物であつて、それらの情報を電子計算機を用いて検索することができるように体系的に構成したもの」と定義しています。
そして、データベースの個々の要素の著作権は、データベースの著作権とは独立しているとされています。ドキュメントも、独自の著作権を備えていますし、ゲームプログラムなどに用いられる、画像や音楽やテキストは、それぞれが独立して著作権を備えています。
◆画面デザイン(ユーザーインタフェース、画面レイアウト)
では、デスクトップアプリケーションや、クライアントサイドのツール、モバイルアプリの画面デザインには、著作権はあるのでしょうか。実をいうと、これらは極めて限定的なものになっています。ゲーム画面中のキャラクターなどは著作権を備えていますが、操作画面は十分な創作性を持っている場合だけ著作権が認められています。
2002年、ネオジャパンのWebグループウエア「iOffice2000」が「サイボウズ Office」を悪質に模倣しているとした裁判があり、サイボウズが敗訴しました(東京地裁平成14年9月5日判決)。「具体的な表現方法を対比したとき，表現上の創作的特徴を共通するということはできない」とされたのです。
ただし、画面レイアウトでも、丸パクリした場合は、不正競争防止法などにより、アウトになる可能性があります。
◆対象の知識(業務知識、ゲームのルール、アイデア)
最後に、ソフトウェアで実現された、業務処理の手順や知識、ゲームのルールなどに著作権はあるのでしょうか。実は、著作権法の対象となるのは「表現」だけです。実際に見える部分、聞こえる部分である「表現されたもの」が対象になるのです。また、意匠や商標として登録して保護することもできます。しかし、考え方やアイデアだけでは、著作物とは見なされません。アイデアを保護するためには、特許を取得する必要があるのです。
2012年、DeNAのモバイル向け釣りゲーム「釣りゲータウン2」が、グリーの「釣り★スタ」の「魚を引き寄せる動作を行う場面」を模倣しているとした裁判があり、グリーが敗訴しました(2012年8月8日 知財高裁判決)。DeNAは、「釣り★スタ」を参考にした可能性があるとされましたが、それはアイデアの模倣であって、著作権侵害ではないと判断されたのです。
このように、ソフトウェアの場合は、その構成要素によって、法律上の保護の範囲や制限の方法が違っているのです。当然、法律上で保護されているものを丸パクリすれば、法律違反になります。法律で保護されていない範囲をパクった場合は、その業界のモラルや社会的なモラルによって、評判が落ちることになるでしょう。
■ソフトウェア開発のパクリ防止で、できること
Photo by Richard-G
それでは、ソフトウェア開発で、パクリ防止のために、どのような開発体制を整えると良いか考えてみましょう。
組織におけるソフトウェア開発は、次のような役割に分かれています。
◆ソフトウェア開発者の場合
まず、組織の一員として、ソフトウェアを開発する「ソフトウェア開発者」がいます。この人たちは、開発企業の従業員になっています。そのために、雇用契約や職務命令に従わなければなりません。職務命令で作成したソフトウェアは、所属している組織の著作物になります。
そして、所属組織の開発体制に従って、流用しても良いソフトウェアと流用してはいけないソフトウェアがあるはずです。たとえば、企業としてライセンスを受けているソフトウェアは、そのライセンスの範囲内で流用可能になっているでしょう。場合によっては、オープンソースソフトウェアは、流用禁止となっていることもあるかも知れません。
ソフトウェア開発者は、このように所属組織の開発ポリシーに従わなければなりません。
◆ソフトウェア開発企業(１次)の場合
それから、１次受けの「ソフトウェア開発企業」があります。自社製品となるソフトウェアやWebサービスを開発している場合は、自社の著作物になります。受託開発をしている場合は、受託開発契約で、著作物の帰属先が定めておくのが一般的です。たとえば、経済産業省が公開している「情報システム・モデル取引・契約書」では、納入物の著作権の条項として、いくつかのサンプルが示されています([参考]産業構造・市場取引の可視化（METI/経済産業省）)。
(発注元にすべての著作権を帰属させる場合)
納入物に関する著作権（著作権法第27条及び第28条の権利を含む。以下同じ。）は、乙又は第三者が従前から保有していた著作物の著作権及び汎用的な利用が可能なプログラムの著作権を除き、甲より乙へ当該個別契約に係る委託料が完済されたときに、乙から甲へ移転する。なお、かかる乙から甲への著作権移転の対価は、委託料に含まれるものとする。
◆開発ポリシー
ソフトウェア開発企業は、最終的な成果物の著作権がどのようになるかに応じて、流用しても良いソフトウェアと流用してはいけないソフトウェアを開発ポリシーとして決める必要があります。たとえば、オープンソースソフトウェアや、ネット上で公開されているコード断片(Code Snippet)をどこまで流用していいのか、コードの流用を誰がどのようにチェックするのか、といった内容です。
オープンソースソフトウェアの場合は、どのようなライセンスになっているのか、きちんと確認して、ライセンスに従って利用しましょう。特に、GPL系ライセンスの場合は、コピーレフト条項により、自社のソースコードまで影響を受ける場合があるので注意が必要です。
もちろん、他者の知的財産を侵害する行為は禁じられています。
ソフトウェア開発企業としては、自社に所属するソフトウェア開発者に対して、この開発ポリシーを守らせるだけでなく、著作権に関する知識を与えたり、ソースコード管理ツールを導入して、いつ誰がどのコードをチェックインしたのか記録していくことが重要でしょう。
◆ソフトウェア開発企業(２次)
ソフトウェア開発企業は、２次受けの開発企業に対しても、開発契約の中で著作権の取扱いを明確にすると共に、２次受けのソフトウェア開発ポリシーと、その運用体制がどうなっているのか確認しておく必要があるでしょう。グループ会社の開発企業であれば、開発ポリシーなど共通化されているかも知れませんが、オフショア開発企業であれば、まったく違ったポリシーを持っている場合もあるでしょう。
逆に、２次受けのソフトウェア開発企業の立場は、１次受けの開発企業が受託開発をする場合と同じになります。
◆ソフトウェアの提供
１次受けのソフトウェア開発企業がソフトウェアを提供する場合、その提供形式によって、パクリを防ぐ環境を整える必要があります。たとえば、ソフトウェアライセンスやサービスライセンスを整備したり、スクリプトなどの難読化を行ったり、といった対策が必要になるでしょう。
◆オープンソースソフトウェア開発の場合
さて、ここまで、組織におけるソフトウェア開発と、組織に所属するソフトウェア開発者を想定して、開発体制について考えてきました。一方で、オープンソースソフトウェアの開発コミュニティなどでも、コードの流用などに注意する必要があります。
自分たちのオープンソースソフトウェアのライセンスによっては、コードの流用により影響を受けることがあります。たとえば、MITライセンスやBSDライセンスで提供されているコードに、GPLで提供されているコードを取り込むと、GPLで提供しなければならない場合があるのです。
また、ライセンスが明示されていないパッチやコード断片などの場合も、取り込むことが難しくなります。オブジェクト指向プログラミング言語Rubyは、バージョン1.9.2において、脆弱性が発見されたとき、セキュリティパッチを取り込めなかったことがありました。これは、提供されたセキュリティパッチのライセンスが不明であったためです。そこで、Rubyのコミッタでない人物が、攻撃を想定したコードの提供を受けて、新たにパッチを書き上げて対応しました([参考]Ruby 1.9.2リリースとWEBrick脆弱性問題の顛末 - 西尾泰和のはてなダイアリー)。
■まとめ
というわけで、ソフトウェア開発において、パクリ問題の基本的なポイントを整理してきました。
言うまでもなく、ソフトウェア開発において、誰かの権利を侵害することはいけないことです。一方で、共有財産として利用できるソフトウェアは、車輪の再発明をすることなく、大いに利用すべきだと思います。同時に、何がパクリになり、何が権利侵害になるのか、きちんとした知識を理解しておくことも、エンジニアとして重要なことだと思います。
この記事が、ITエンジニアの皆さんのお役に立てば幸いです。
paizaは、技術を追い続けることが仕事につながり、スキルのある人がきちんと評価される場を作ることで、日本のITエンジニアの地位向上を目指したいと考えています。
「paiza転職」は、自分のプログラミング力が他社で通用するか（こっそり）腕試しができる、IT／Webエンジニアのための転職サービスです。プログラミングスキルチェック（コーディングのテスト）を受けて、スコアが一定基準を超えれば、書類選考なしで複数の会社へ応募ができます。
まずはスキルチェックだけ、という使い方もできます。すぐには転職を考えていない方でも、自分のプログラミングスキルを客観的に知ることができますので、興味がある方はぜひ一度ご覧ください。
また、paiza転職をご利用いただいている企業の人事担当や、paiza転職を使って転職を成功した方々へのインタビューもございます。こちらもぜひチェックしてみてください。
詳しくはこちら
