オープンソース・ライセンスを選ぶ

Mary-E.-Tyler（2004年7月26日（月））
シェア
Open Source Initiative（OSI）では、承認済みのオープンソース・ライセンスが50件以上リストに登録されている。似通ったライセンスもあれば、著しく異なるライセンスもある。これらのライセンスは、法律家のために書かれたもので、浮世のソフトウェア開発者のために書かれたものではない。では、自分のプロジェクトに最も適したオープンソース・ライセンスを選ぶにはどうすればよいだろう。
米Rosenlaw and Einschlagの共同創立者Lawrence Rosenは、OSIの顧問弁護士を勤めており、最近『Open Source Licensing: Software Freedom and Intellectual Property Law』という書籍を執筆した。彼によると、すべてのオープンソース・プロジェクトにぴったりするライセンスは存在しない。「『御社のソフトウェアについて教えてくれませんか』と、私は尋ねますね。コードの全体ではなく、一部だけをオープンソース化したい企業があるのです」と、Rosenは語る。そういった企業に助言するには、「彼らの製品について理解しなければならないのです」。

GNU Public License（GPL）のようなライセンスに基づくオープンソース・ソフトウェアから派生したソフトウェアの場合、それ以外のライセンスを選べないことがある。「[相互性は]ありふれた条件です」と、Rosenは語る。「[オープンソース・ライセンスの]少なくとも半分に、相互性の条項があります。つまり、GPLプログラムからの派生物はGPLである必要があるのです」

もちろん、製品が複数のオープンソース・ソフトウェアに由来する場合、2つのライセンスを結び合わせるのは厄介な仕事になる。たとえば、一方の構成要素がGPLで、他方がApache Software License（ASL）だとしよう。GPLには相互性の条項があるが、ASLにはない。「[開発者が]Aからこれ、Bからそれ、といった具合に使うと、AのライセンスとBのライセンスを統合しなければなりません。ゼロからのスタートではないのです」と、Rosenは言う。「複雑になりますね」。

オープンソースに由来しないソフトウェアの場合、手順は簡単にも複雑にもなりうる。まず、製品をオープンソースにするかどうかを決定しなければならない。Rosenの著書によると、オープンソース以外にも複数のモデルがある。「シェアードソース」は、ソースコードを見て調べることを顧客に認めるが、変更したり独自の製品の開発に利用したりすることは認めない。「パブリックソース」は、非営利目的（具体的な意味はライセンスで定義される）に限って、変更と製品開発への利用を認める。企業は、製品を複数のライセンスの下に提供できる。公認されたコピーを自社の製品に統合したい顧客には商用ライセンスを提供すれば、GPLライセンスの責務を課すことは避けられる。たとえば、MySQLは、取引条件（commercial terms）とGPLの両方でライセンスされる。これ以外に、現バージョンの製品は商用ライセンスとするが、そこから派生するソフトウェアは伝統的なオープンソース・ライセンスでリリースすると定めたライセンス方式もある。

こういったライセンス方式の一部は、熱心なオープンソース・コミュニティから邪道扱いされているが、企業としては、製品のオープンソース化に味方する、あるいは少なくとも敵対しないビジネスケースがないことには話にならない。安く売った後でも製品から収益を得られるのか、企業が知りたいのはそこである。Rosenは、わかりやすくスーパーマーケットでの買い物にたとえている。「[製品を]安く売る場合、無料の品物を高価な品物を売るための特売品としなければなりません」。この品物（専門用語で”従物（appurtenance）“）は、ソフトウェアを実行するハードウェアであったり、ソフトウェアをインストール、保守、サポート、または統合するサービスであったりする。

また、企業は、自社のオープンソース製品を利用して他人が利益を上げてビタ一文還元しなくても逆らえない、という事実を甘受しなければならない。Rosenによると、このタダ乗り問題を阻止するためにできることがある。「最初の課題は、GPLのような相互性ライセンスと[ソフトウェアを]プロプライエタリ化できる学術ライセンスのどちらを望むかです」とRosenは言って、これがオープンソース・コミュニティ全体を巻き込む大論争となっているトピックであることを認めた。「相互性ライセンスを選んだ場合、次はどのライセンスを選ぶかが問題になります。GPLには”プログラムに基づく物”と書かれています。このあいまいな表現が人を不安にさせるのです。Mozilla [Public] License（MPL）は相互性ライセンスですが、[“オリジナルのコード”（MPL 1.1節を参照）を含む]ファイルを作成した場合、このファイルをリリースしなければなりません」

Rosenによると、他にも考慮すべきことはたくさんある。相互性ライセンスを選んだ場合、GPLのような”派生物”という広い定義を選ぶか、それともMPLのような狭い定義を選ぶかを決める必要がある。あるいは、CPLのようなものが望ましいかもしれない。CPLは、何が派生物で何がそうではないかの定義を著作権法に委ねる。どの特許をライセンスするか（特許がある場合）、そのライセンスをすべての派生物に受け継がせるかどうかを考慮しなければならない。下流の開発者を特許侵害の訴えから保護したいのか。被保証者と責任、またはそれに類するものの放棄も考慮する必要がある。司法権──すべてのクレームが法廷に持ち込まれるようにする──や準拠法（契約なのか著作権なのか、あるいはその両方なのか）などの問題も考慮しなければならない。誰かに訴えられるか、自分がライセンス保持者を訴える場合、弁護費用は誰が負担するのか。ライセンスは、これらの問題をすべて網羅してなければならない。

「多数の企業に多数のライセンスがあるので、それぞれの違いと、自社製品にどう適用されるかをよく考える必要がありますね」と、Rosenは注意を促す。「フリーサイズの万能ソリューションはありません」