(1/2)オープンソースソフトウェアについて解説した記事の中には、「OSSライセンスは契約である」という誤解を目にすることが多い。佳作に入選した論文をベースに、その誤解を解いてみるという試みをしたい。});問題意識:OSS開発者が条件を指定する権利はどこに由来するのか前回の連載「企業技術者のためのオープンソースソフトウェア(OSS)ライセンス入門」では、企業がオープンソースソフトウェア(OSS)とうまく付き合っていくためのポイントを、ライセンスという観点から解説した。それから6年が経過した。当時もそうだったが、OSSはますます広がり、企業が新たなビジネスやサービスを展開する際に利活用するのはもちろん、自らの成果物をオープンソースとして公開することも珍しくはなくなった。一方で、筆者にはどうしても気になる誤解も増えている。報告書をはじめ、弁護士や大学教授などの法学専門家によるGPLの解説記事はこれまでに数多く記されてきた。情報が少なかった当時、それらは貴重な情報であったが、ほぼ例外なく、これらの条文を「契約」と解することを前提にしていたものだったようだ。今となっては、「OSSライセンスは契約である」という「債権を権原とした解釈」は、誤解を招きやすいように思われる。いうのも、OSSにかかわる開発者や利用者の間では、OSSライセンスは基本的に契約として扱われていないのが現状だからだ。かかわらず、OSSに直接的にかかわらない人の多くは、こうした解説記事を見ると「OSSライセンスは契約だ」と理解してしまっている。加えて、民法になじみのない人ほど、契約というものを「紙にサインする契約書」のイメージで捉え、さらに誤解を増長させているようだ。その誤解に基づいてOSSに対応しようとする企業があるなど、弊害も見られるようになった。この記事はそうした誤解を解くことを目的としたものだ。OSSライセンスを「債権を権原とした解釈」から、「著作権を権原とした解釈」に見直すきっかけになれば幸いである。著作権法を権原とした解釈」を元にしている。論文要旨はNECのサイトに掲載されているが、これに大幅に加筆修正を加え、6回に分けて掲載していく。著作権を権原とした解釈」とすべきであった。これは、「OSS開発者が、OSSライセンス条文でいろいろな条件を指定する権利はいったいどこから来るのか」という意味で使用した。その疑問を明らかにしようとしたことが、そもそも論文執筆の契機となっている。「権原」ならば「著作権」であるが、いろいろと調べていくうちに「著作権法」を強く意識し、論文タイトルで「著作権法を権原とした」と用いてしまった。法学の専門家ではないゆえの用法であった点、ご容赦いただきたい。OSSライセンス=「ライセンス契約」という誤解この記事は、OSSのライセンスが「著作権によって利用の許諾の条件が示されたものである」と解釈することの妥当性を検討することを目的とする。Server」など、インターネット関連のコンピュータープログラム(以下、プログラム注1と略す)が数多く存在している。OSSはさまざまな用途で利用されている。かかわらず、その理解、とりわけライセンスに関わる理解は浸透しているとは言い難い状況だ。OSSライセンスを、従来の(ソースコード注2が入手できない)商用ソフトウェア(プロプライエタリ・ソフトウェア)のソフトウェアライセンスと同じ視点で、「ライセンス契約」として解説しているものがある。図1注1:ソフトウェアはプログラムとその取扱説明書など関連文書を含む場合があるが、ここでは特に使い分けずに使用する(@ITの読者にとっては余分な説明かもしれないが、法務関係者向けの論文であったためこのような解説を追加していた。参考までにそのまま残すことにするので、ご容赦願いたい)注2:プログラムについて簡単に説明する(上記図1)。プログラムは、言語Cなどプログラミング言語を用いて、人が見える形のテキスト(hello.cなどのテキストファイル)で記述し、作成(開発)する。-cなど)を用いて、コンピューターが読み取り可能なマシン語(機械語)に変換する。この元となるテキストを「ソースコード」と呼び、それをコンパイラーなどで変換したものを「オブジェクトコード」と呼ぶ。-oなど)で結合(リンク)することにより、コンピュータ上で実行可能な「実行形式」となる。どの形式であってもプログラムと呼ぶ。マシン語など人が読み取り困難なもの、つまり、オブジェクトコードおよび実行形式などは「バイナリ(コード)」とも呼ぶ。商用ソフトウェアの商品では、このバイナリコードのみが提供され、ソースコードは提供されないため、一般には改修するなどプログラムに変更を加えることは困難である。OSSライセンス違反(2/2)」で述べたように、商用ソフトウェア(パッケージソフトウェア)のライセンスは、主に(著作権法で言うところの)「使用」のライセンスであるのに対し、OSSのライセンスは主に、(オーバーラップするところがあるにしても)「利用」のライセンスである点が大きな差異である。この現実を正しく認識することによりOSSライセンスを理解しやすくなるだろう。frauds)として、原則として契約の成立には書面の作成を必要とする」と述べている。OSSライセンスは、多くが米国で作成されたにもかかわらず、サインを求めるような契約書の体裁を取っていない。このことからも、契約を意図していなかったと捉えるのが妥当であろう。この他にも、英米法では「約因」(consideration)、つまり「対価性」が存在しなければ、契約として認められない。契約とは、1個または1組の約束であって、その違反に対して法が救済を与え、または何らかの形でその履行を義務として認めるものをいう。ページ:16-17]では、以下のように述べている。すべての約束は契約とは限らないこと、そしてそれに基づく訴えを裁判所が認めてくれるというわけではないという点に留意すべきである。(中略)問題は、いかなる場合に法的効果を認めるか認めないかであり、そこにアメリカ法の特色を探ることが、本書の課題の1つとなる。(中略)結論的にいえば、アメリカの裁判所は交換取引(exchange)の保護を図ってきた。言い換えれば、ある約束が破られたとしても、その約束に対して何らかの対価(約因)が存在するような取引でない限り、当該約束を法的保護に値しないとみてきた。約因という要件は、英米法の最も大きな特色とされてきた点であり、後の第5章で、より詳しく述べる。繰り返すが、OSSの開発者、そしてOSSライセンスの作成者の多くがアメリカ人である。そのため、彼らの意図を探るに当たって、アメリカ法を参照した。日本国内の法律の感覚だけで彼らの意図を断じるのはどうかと思うからである。ライセンスは「不作為請求権を与える法律行為」と説明される場合もある。(ロイヤリティとしての)ライセンス料を支払うなど、何らかの約因があれば、米国でも契約と認められるかもしれない。それがないOSSライセンスの場合は、やはり、契約を意図していないと捉えるのが妥当ではないだろうか。開発者も「何も、不作為請求権なんて立派な権利を与えたつもりはない」と言いたいところではないかと思う。日ごろ契約書の作成、確認を主な業務としている法務関係者は、日米欧を問わず、物事を契約と捉えたがる傾向にあるようだ。neck!”(うんざりする!)と辟易しているようである(関連リンク)。choice.著作権法は、国家間で、契約法や他のあり得る選択より、非常に均質である。copy.コピーを提供する前に契約へのユーザーの正式な同意を得ることを、あらゆる頒布者に要求すること。forbidden.最初に彼のサインをすることなく誰かにCDを手渡すことは、禁じられている。neck!うんざりする!出典:http://www.gnu.org/philosophy/no-ip-ethos.htmlまたOSSライセンスの現場を見ても、サインを求めるような運用はされていない。そのようなOSSライセンス条文を、契約書条文がごとく理解すると、本来の意図とは異なってくるため不都合が生じる。中には、これを条文の不備であるかのように指摘し、OSSライセンスは「契約として成立しているかどうか疑わしい」とする解説も見かける。一部には、これをもって「契約による制約、つまり義務があるか否か疑わしい」と、著作権を無視した議論が展開されることを見かけることさえある。本稿では、OSSライセンスの条文を「契約の債権を権原として書かれたもの」ではなく、「著作権を権原として書かれたもの」として扱うことによって、その内容をより適切に理解できることを提示していきたい。この記事の趣旨は、「OSSライセンスは契約ではないことを証明する」ことではない。後述するように、そうした誤解に基づいて作成されたOSSライセンスも存在する。現実の運用から、またGPLなどの作成意図から考えると、OSSライセンスを「契約」と解して理解することには不都合が多い。素直に「著作権の許諾条件」と考えることにより、内容がより理解しやすくなることを提示していきたい。2005]の新書を読んで、著作権の考え方の入り口に立つことができた。4章で再検討を試みているソフトウェア情報センター(SOFTIC)や情報処理推進機構(IPA)の報告書は、2003年度/2004年度の研究会活動の内容に基づいている。それから10年以上立った今、「私が知らないだけで、研究者の間では既に認識が是正されているのではないか?」という不安があったが、[志賀典之,2009]の研究ノートに数少ない参考文献として、SOFTICの報告書が挙げられているのを見て、この論文を執筆する価値があると思った次第である。