「OSSライセンス＝契約」という誤解を解く：OSSライセンスで条件を指定する権利はどこからくるのか？（1/2 ページ）
オープンソースソフトウェアについて解説した記事の中には、「OSSライセンスは契約である」という誤解を目にすることが多い。この連載は「第9回著作権・著作隣接権論文」で佳作に入選した論文をベースに、その誤解を解いてみるという試みをしたい。
問題意識：OSS開発者が条件を指定する権利はどこに由来するのか
前回の連載「企業技術者のためのオープンソースソフトウェア（OSS）ライセンス入門」では、企業がオープンソースソフトウェア（OSS）とうまく付き合っていくためのポイントを、ライセンスという観点から解説した。
それから6年が経過した。当時もそうだったが、OSSはますます広がり、企業が新たなビジネスやサービスを展開する際に利活用するのはもちろん、自らの成果物をオープンソースとして公開することも珍しくはなくなった。だが一方で、筆者にはどうしても気になる誤解も増えている。それが、「OSSライセンスは契約である」とする解説だ。
経済産業省外郭団体の報告書をはじめ、弁護士や大学教授などの法学専門家によるGPLの解説記事はこれまでに数多く記されてきた。情報が少なかった当時、それらは貴重な情報であったが、ほぼ例外なく、これらの条文を「契約」と解することを前提にしていたものだったようだ。しかし今となっては、「OSSライセンスは契約である」という「債権を権原とした解釈」は、誤解を招きやすいように思われる。 というのも、OSSにかかわる開発者や利用者の間では、OSSライセンスは基本的に契約として扱われていないのが現状だからだ。
にもかかわらず、OSSに直接的にかかわらない人の多くは、こうした解説記事を見ると「OSSライセンスは契約だ」と理解してしまっている。加えて、民法になじみのない人ほど、契約というものを「紙にサインする契約書」のイメージで捉え、さらに誤解を増長させているようだ。その誤解に基づいてOSSに対応しようとする企業があるなど、弊害も見られるようになった。
この記事はそうした誤解を解くことを目的としたものだ。OSSライセンスを「債権を権原とした解釈」から、「著作権を権原とした解釈」に見直すきっかけになれば幸いである。
なおこの連載は、公益社団法人著作権情報センター（CRIC）が2013年9月3日に発表した「第9回著作権・著作隣接権論文」に筆者が個人的に応募し、佳作に入選した論文「OSS ライセンスとは - 著作権法を権原とした解釈」を元にしている。論文要旨はNECのサイトに掲載されているが、これに大幅に加筆修正を加え、6回に分けて掲載していく。
実は、論文のタイトルは「OSSライセンスとは - 著作権を権原とした解釈」とすべきであった。これは、「OSS開発者が、OSSライセンス条文でいろいろな条件を指定する権利はいったいどこから来るのか」という意味で使用した。その疑問を明らかにしようとしたことが、そもそも論文執筆の契機となっている。「権原」ならば「著作権」であるが、いろいろと調べていくうちに「著作権法」を強く意識し、論文タイトルで「著作権法を権原とした」と用いてしまった。法学の専門家ではないゆえの用法であった点、ご容赦いただきたい。
OSSライセンス＝「ライセンス契約」という誤解
この記事は、OSSのライセンスが「著作権によって利用の許諾の条件が示されたものである」と解釈することの妥当性を検討することを目的とする。
OSSとしては、AndroidベースのスマートフォンやデジタルTV、証券取引所や銀行など、幅広いコンピューターシステムのOSとして使われている「Linux」（リナックス／リヌクス）をはじめ、Webサーバーの「Apache HTTP Server」など、インターネット関連のコンピュータープログラム（以下、プログラム注1と略す）が数多く存在している。
OSSはさまざまな用途で利用されている。にもかかわらず、その理解、とりわけライセンスに関わる理解は浸透しているとは言い難い状況だ。例えばOSSライセンスを、従来の（ソースコード注2が入手できない）商用ソフトウェア（プロプライエタリ・ソフトウェア）のソフトウェアライセンスと同じ視点で、「ライセンス契約」として解説しているものがある。
図1注1：ソフトウェアはプログラムとその取扱説明書など関連文書を含む場合があるが、ここでは特に使い分けずに使用する（@ITの読者にとっては余分な説明かもしれないが、法務関係者向けの論文であったためこのような解説を追加していた。参考までにそのまま残すことにするので、ご容赦願いたい）
注2：プログラムについて簡単に説明する（上記図1）。プログラムは、言語Cなどプログラミング言語を用いて、人が見える形のテキスト（hello.cなどのテキストファイル）で記述し、作成（開発）する。これを コンパイラーと呼ぶプログラム（gcc -cなど）を用いて、コンピューターが読み取り可能なマシン語（機械語）に変換する。この元となるテキストを「ソースコード」と呼び、それをコンパイラーなどで変換したものを「オブジェクトコード」と呼ぶ。オブジェクトコードは、必要な他のオブジェクトコードとリンカと呼ばれるプログラム（gcc -oなど）で結合（リンク）することにより、コンピュータ上で実行可能な「実行形式」となる。どの形式であってもプログラムと呼ぶ。また、マシン語など人が読み取り困難なもの、つまり、オブジェクトコードおよび実行形式などは「バイナリ（コード）」とも呼ぶ。商用ソフトウェアの商品では、このバイナリコードのみが提供され、ソースコードは提供されないため、一般には改修するなどプログラムに変更を加えることは困難である。
図2前連載「企業技術者のためのOSSライセンス入門（1）訴訟が増えている!? OSSライセンス違反（2/2）」で述べたように、商用ソフトウェア（パッケージソフトウェア）のライセンスは、主に（著作権法で言うところの）「使用」のライセンスであるのに対し、OSSのライセンスは主に、（オーバーラップするところがあるにしても）「利用」のライセンスである点が大きな差異である。この現実を正しく認識することによりOSSライセンスを理解しやすくなるだろう。
しかし、［山本隆司, 2008, ページ: 188］は、OSSライセンスについて「日本では、契約は原則として合意のみによって成立し、契約書の作成を必要としない」ため、契約と捉えることも可能であるが、「これに対して、米国では、コモン・ローの詐欺防止法（statute of frauds）として、原則として契約の成立には書面の作成を必要とする」と述べている。OSSライセンスは、多くが米国で作成されたにもかかわらず、サインを求めるような契約書の体裁を取っていない。このことからも、契約を意図していなかったと捉えるのが妥当であろう。
この他にも、英米法では「約因」（consideration）、つまり「対価性」が存在しなければ、契約として認められない。
アメリカ契約法 第1条 契約の定義
契約とは、1個または1組の約束であって、その違反に対して法が救済を与え、または何らかの形でその履行を義務として認めるものをいう。
これについて［樋口範雄, 2008, ページ:16-17］では、以下のように述べている。
まず、すべての約束は契約とは限らないこと、そしてそれに基づく訴えを裁判所が認めてくれるというわけではないという点に留意すべきである。（中略）問題は、いかなる場合に法的効果を認めるか認めないかであり、そこにアメリカ法の特色を探ることが、本書の課題の1つとなる。（中略）結論的にいえば、アメリカの裁判所は交換取引（exchange）の保護を図ってきた。言い換えれば、ある約束が破られたとしても、その約束に対して何らかの対価（約因）が存在するような取引でない限り、当該約束を法的保護に値しないとみてきた。約因という要件は、英米法の最も大きな特色とされてきた点であり、後の第5章で、より詳しく述べる。
繰り返すが、OSSの開発者、そしてOSSライセンスの作成者の多くがアメリカ人である。そのため、彼らの意図を探るに当たって、アメリカ法を参照した。日本国内の法律の感覚だけで彼らの意図を断じるのはどうかと思うからである。
ライセンスは「不作為請求権を与える法律行為」と説明される場合もある。（ロイヤリティとしての）ライセンス料を支払うなど、何らかの約因があれば、米国でも契約と認められるかもしれない。しかし、それがないOSSライセンスの場合は、やはり、契約を意図していないと捉えるのが妥当ではないだろうか。開発者も「何も、不作為請求権なんて立派な権利を与えたつもりはない」と言いたいところではないかと思う。
日ごろ契約書の作成、確認を主な業務としている法務関係者は、日米欧を問わず、物事を契約と捉えたがる傾向にあるようだ。リチャード・ストールマン氏も、米国の弁護士の「契約でなければ執行（enforce）されないでしょ」的なご意見に、以下のように” What a pain in the neck!”（うんざりする！）と辟易しているようである（関連リンク）。
Don't Let ‘Intellectual Property’ Twist Your Ethos
by Richard M. Stallman
June 09, 2006Most free software licenses are based on copyright law, and for good reason:
（筆者素訳）ほとんどの自由ソフトウェアのライセンスは、著作権法と、正当な理由に基づいている：つまり、Copyright law is much more uniform among countries than contract law, which is the other possible choice.
著作権法は、国家間で、契約法や他のあり得る選択より、非常に均質である。There's another reason not to use contract law:
契約法を使わないもう一つの理由は、It would require every distributor to get a user's formal assent to the contract before providing a copy.
コピーを提供する前に契約へのユーザーの正式な同意を得ることを、あらゆる頒布者に要求すること。To hand someone a CD without getting his signature first would be forbidden.
最初に彼のサインをすることなく誰かにCDを手渡すことは、禁じられている。What a pain in the neck!
うんざりする！
またOSSライセンスの現場を見ても、サインを求めるような運用はされていない。そのようなOSSライセンス条文を、契約書条文がごとく理解すると、本来の意図とは異なってくるため不都合が生じる。
中には、これを条文の不備であるかのように指摘し、OSSライセンスは「契約として成立しているかどうか疑わしい」とする解説も見かける。さらに一部には、これをもって「契約による制約、つまり義務があるか否か疑わしい」と、著作権を無視した議論が展開されることを見かけることさえある。
しかし本稿では、OSSライセンスの条文を「契約の債権を権原として書かれたもの」ではなく、「著作権を権原として書かれたもの」として扱うことによって、その内容をより適切に理解できることを提示していきたい。
なおこの記事の趣旨は、「OSSライセンスは契約ではないことを証明する」ことではない。後述するように、そうした誤解に基づいて作成されたOSSライセンスも存在する。しかし現実の運用から、またGPLなどの作成意図から考えると、OSSライセンスを「契約」と解して理解することには不都合が多い。素直に「著作権の許諾条件」と考えることにより、内容がより理解しやすくなることを提示していきたい。
余談となるが、私自身は、この論文中に挙げた参考文献に加え［福井健策, 2005］の新書を読んで、著作権の考え方の入り口に立つことができた。
また、4章で再検討を試みているソフトウェア情報センター（SOFTIC）や情報処理推進機構（IPA）の報告書は、2003年度／2004年度の研究会活動の内容に基づいている。それから10年以上立った今、「私が知らないだけで、研究者の間では既に認識が是正されているのではないか？」という不安があったが、［志賀典之,2009］の研究ノートに数少ない参考文献として、SOFTICの報告書が挙げられているのを見て、この論文を執筆する価値があると思った次第である。 あらためて、諸氏に感謝したい。
Copyright © ITmedia, Inc. All Rights Reserved.
ITmediaはアイティメディア株式会社の登録商標です。