メタライセンシング：Magi's View

FOSSの世界ではさまざまなライセンスが存在するが、その多くがクロスライセンス共有を認めていない。それがもたらす問題を考えるとともに、その解決の糸口となるかもしれない特殊なライセンスについて考えてみよう。

[Grigor-Gatchev，SourceForge.JP Magazine]

　フリー／オープンソース・ソフトウェア（FOSS）の世界では、さまざまなライセンスが利用されている。このような充実したラインアップには、メリットもデメリットもある。コードの利用者にどこまでの作業を認めるかは開発者によって違うため、別々のライセンスが必要になるが、その一方で、ライセンスの多くは、他のライセンスが適用されている製品の中でコードを使用すること（クロスライセンス共有）を認めていないのだ。しかし、この問題を解決できるかもしれない特殊なライセンスがある。それがメタライセンスだ。

　フリー・ライセンスの選択肢が多いことは良いことだ。開発者が、作品を他の人々に利用してもらう上で、自らの意向に合ったライセンスを見つけられなかったとしたら、その作品をフリー・ソフトウェアとして公開すること自体を思いとどまってしまうかもしれないからだ。オープンソースの世界には、ソフトウェアの利用に何の制約も設けないBSDタイプのライセンスから、そのソフトウェアの派生物もフリーであることを要求するGPLタイプのライセンス（コピーレフト・ライセンスともいう）までさまざまなライセンスがある。

　しかし、この豊富なライセンスが、FOSSにとって不利になることもある。オープンソースのコード・プールをライセンスごとに断片化してしまうため、FOSSの最大の特長である共有コード・ベースの成長を阻むことになりかねないのだ。

　多種多様なライセンスの間にあるこのような境界線は、あまり守られていないのが現状だ。大規模なFOSSパッケージのほとんどで、コードプールの一貫性を維持するために、「違法な」クロスライセンスのコード共有が行われている。この慣例を問題視する人は少ないが、今後問題に発展させないためにも、解決することが望ましい。

　それぞれに目的があるからこそ、さまざまな種類のライセンスが生まれたのであり、ライセンスの断片化を防ぐことはできない。しかし、法的な観点からは、FOSSプールはすでにかなり断片化が進んでいるといえる。大部分はGPLの管理下にあるが、現在、「GPLタイプ」や「BSDタイプ」のライセンスは数多くある。今後もこの傾向が続くなら、近い将来、FOSS内でライセンス戦争が勃発するだろう。これは意義のない争いであり、何としても防がなければならない。

　考えられる方策の1つは、似たライセンスの利用者たちが、全員が納得できるライセンスをいくつか決め、そこから1つのライセンスを作ることだ。しかし、このようなアプローチが不可能な場合も多く、仮に可能であっても、妥協を成立させ、それを維持するのは難しい。

　もう1つの方法は、これらのライセンス利用者たちの交渉を仲裁し、フリー・ライセンス間のコード共有を可能にする「クロスライセンス」を成立させることだ。しかし、これも成功の見込みは少ない。似てはいるが共有できないライセンスは、共有を成立できない理由があって作成されたはずだからだ。

　これらの問題を解決する3つ目のアプローチが、メタライセンシングだ。

メタライセンシングの基本

　最もシンプルなメタライセンスは、リストに含まれるすべてのライセンスにおけるコードの利用を許可するライセンスだ。要件や既定が定められた、もっと複雑なものもある。

　メタライセンスは、コピーレフトのFOSSライセンスで要求される非共有の要件を合法的に回避できる。例えば、SunのCDDLまたはGPLでの利用を許可するメタライセンスの下でコードをライセンシングすれば、CDDLとGPL、どちらでライセンシングされたソフトウェアにも、このコードを含めることができる。さらに、このコードの派生物も同じメタライセンスでライセンシングすれば、同じようにCDDLとGPLの両方に対応できる。多くのコピーレフト・ライセンスで共有が禁止されているのは、コードを束縛するためではなく、コードの自由を守るためなので、コードを複数のコピーレフト・ライセンスにメタライセンシングすることが、コピーレフトの精神と矛盾することはない。

　開発者は、当初の目的どおりにコードが利用されるよう、ライセンスのリスト自体の管理を信用された機関に委託することもできる。つまり、メタライセンス自体が非共有であっても、開発者が指定した範囲内のライセンスでコードを利用できる。新しいライセンスができたときには、リストの管理者が、開発者が設けた基準に合致するかどうかを確認し、合致すればこれをメタライセンスに含める。こうすれば、開発者は新しいライセンスに常に注意して、コードを何度もライセンシングし直さなくて済む。

　メタライセンスは、本文をきちんと作成しておけば、許可するライセンスのリストだけを変更して使うことができるだろう。

　リスト内のライセンスがメタライセンスであってもかまわない。開発者は、許可するライセンスを階層構造で指定できる。ライセンスの種類と関係について把握するのにも役立つだろう。開発者は法律用語よりも階層構造のほうが得意だろうから。 ;-)

　メタライセンスを特定のライセンスと比較した場合の大きなメリットを以上に挙げた。新しいコードは、特定のライセンスに加えてメタライセンシングを行ってもよいし、メタライセンシングだけを行ってもよいだろう。既存のコードは、メタライセンスによって再度ライセンシングする。メタライセンシングされたコードが増えるに従って、FOSSコード・プールの断片化が解消されていく。これは誰にとっても喜ばしいことだ。

　メタライセンスの文面の例は、筆者のサイトを参照してほしい。

原文へのリンク