目次


Geronimoへの転向: Geronimoについて、そしてApacheライセンスの苦闘と収穫

Neal Sancheの目から見たオープンソース・ライセンス

Comments

夢の世界にようこそ

私は、まだそれほど年を取ってはいません。これは本当です。私の経験は、パンチカードやトグル・スイッチ、トランジスターや真空管などの昔にまではさかのぼりません。私の最初のコンピューター経験は、ダム・ターミナル(dumb terminal)や緑色の蛍光体のモニター、ライトペン、それに三目並べ(tic-tac-toe)などの楽しいゲームくらいのものです。しばらく後、オブジェクト指向技術が出現し始めた頃、私は正にそこにおり、学習意欲に燃えていました。私は今でも、1990年代初期の楽観主義を覚えています。つまり近い将来には、下位レベルのオブジェクト指向構成ブロックは、全て既に書かれており、私達は単純にクリックして数多くの構成ブロックをかき集めるだけで、そうしたプラットフォーム上に新しいアプリケーションを書けるようになる、と思われていたのです。これは、子供の頃に夢中になった、レゴ(Lego®)ブロックを思い出させる話でした。では、よく設計された最初の小片が幾つかありさえすれば、全世界が構成できる、というのは本当なのでしょうか。

Apache Geronimoアプリケーション・サーバー・プロジェクトは、商業的に使いやすいApacheライセンスの下でライセンスされています。そのため、私が子供の頃の思い出として覚えている構成ブロックが、大きな箱になったようなもの、となるかも知れません。基本的なパズル片を毎回実装し直さずにすむよう、基礎のコードを作り上げることを開発者達が遂に考え始めたことは、歓迎すべきことです。この、下位レベルプラットフォーム実現の鍵となるのが、Apacheライセンスそのものです。このライセンスが無ければ、全く異なった結果になるでしょう。

異なる2つの世界

皆さんのために、2つの図を描いてみましょう。最初の図は、「バラバラに分かれた沈滞」です。ここでは、歪んだ、薄汚れたライセンスの背後から、孤立した大量のソースコードが、未達成の栄光という光を鈍く放っています。2番目は、「現実の姿」です。ここでは、足取りも軽やかなオープンソースへの転向者達が既に勝利を勝ち取り、将来の世代のための基盤を注意深く築こうとしています。そして、弾丸も通さない堅牢なライセンス文が、壁に飾られたガラスケースの中で白く輝いています。この、全く異なる2つの図は、皆さんも見慣れたものではないでしょうか。皆さんの中には、オープンソースの旗印の下に、長年勇敢に戦っている人もいるでしょう。そして、不透明なライセンスに行く手を阻まれ、パズルの次の小片を追加できず、次世代の万里の長城が完成できずにいるのではないでしょうか。

最初の図では、ソフトウェアは会社が所有しており、こうした会社が、ライセンス販売によってソフトウェア使用権を売りさばきます。多くの場合、こうしたライセンスはソースコードさえ含んでいません。そのためソフトウェア購入者は、バグを報告し、ソフトウェアの所有者が購入者の要求に応じてくれるのを望む以外、そのソフトウェアの品質にかかわることはできないのです。時にはソフトウェアにソースコードが含まれる場合もありますが、ライセンス条件から、そのソースコードを他の製品のために使用することは禁止されています。

2番目の図は、ずっと明るいものです。非常に高度にオープンとなっており、ソースコードは自由に入手でき、時には無料のソフトウェアを使って商用のソフトウェアを書くこともできます。では次に、主なオープンソース・ライセンスの仕組みを調べることにしましょう。

2つの柱

知的財産(intellectual property)に関しては、過去20年ほどの間に大きな動きが起こってきました。つまり考え方の学習、共有を推進するために、見える形での料金を払うことなく知的財産を公開共用する、という動きです。様々な開発者が、様々なライセンスを書きました。これらのライセンスでは、学習のために、あるいは非商用目的のために、考え方を無料でやり取りできるだけではなく、彼らのオープンソース・コードを使って利益を得るという、商用努力にも機会を与えたのです。こうした開発者が対価として要求したことといえば、それを元々書いた人が、その創作物に対して一定の権利を保持できるよう、帰属(attribution、作成者を明示するもの)が確保できること、著作権が維持される、ということだけです。

ここで2つのタイプのライセンスが、フリー・ソフトウェアの動きを支える2つの柱としての役割を果たしています。つまりGPL(GNU Public License)とそのファミリー変種、そして、よりオープンな(ビジネス向きの)ライセンス、例えばBSDやApacheライセンスなどです。GPLは、学術上の目的に基づく研究調査活動や開発が、非好意的な経済活動の中で破壊されることなく発展するよう、学術目的の活動を許しています。ソースコードや、そこから派生するものは、すべて同じライセンスの下に置かれる一方、ビジネスは、ビジネス用に使用できるかどうかをライセンス所有者と交渉しない限り、自由にコードを使えません。GPLの派生として、GPLよりも制限は緩いものの、やはりGPLクラスのライセンスとして、LGPL(Lesser GPL)と呼ばれるものがあります。LGPLでは、帰属と著作権が明記されており、対象ソフトウェアが何ら変更されない限り、コード・ライブラリーを商用ソフトウェアに使用することを許しています。ですからLGPLは、BSDやApacheライセンスに近い「いとこ」ですが、BSDやApacheライセンスはさらに制限が緩く、変更することや、商用ソフトウェアの中に含めることを許しているのです。

中間が無い

GeronimoプロジェクトのJeff Genenderが最近のインタビュー(参考文献にリンクがあります)の中で語っている通り、Apache Geronimoプロジェクトは、自分なりに構成できるアプリケーション・サーバーを構築するための活動を、既に何年にも渡って行っています。彼らのライセンス、つまりApacheライセンスが非常に明確にしているのは、このソース・ベースを書いた人達が望むものが完全に実現できた時には、他の技術とは比較にならないほど強力にビジネスを推進するものとなる、ということです。彼らには夢があり、その夢を実現するために、他とは一線を画しているのです。

LGPLと、Apache Geronimoライセンスが求めるものとの基本的な違いの一つは、次の通りです。Apacheライセンスでは、ソースコードの変更部分を明確にするために、自分が行った変更を追跡する必要があります。しかし変更は自由に行うことができ、さかのぼってソース・プールに貢献する必要はありません。つまり、皆さんのビジネスをサポートするために、必要な変更を行うことはOKなのです。ライセンスを見れば分かる通り、Apache 2.0ライセンスは容易に読めるものであり、理解できるものであり、信頼できるものです。ではGeronimo開発者は、他のオープンソース・ライセンスには、どう対処するのでしょう。完全なアプリケーション・サーバーをリリースするためにパズルの小片を組み合わせようとすると、こうしたライセンスに必然的に突き当たるものです。

Geronimoが持つ多くの依存部分(他のライブラリーからのソースコードに依存する部分)を調べてみると、こうしたライブラリーが持っているライセンスは、どれもApacheライセンスと互換性があるのです。Geronimo開発チームは、彼らのライセンスを否定する、あるいは傷つけるような、他のライセンスを取り入れたり、含めたりしないよう、非常に注意してきました。これは非常に有益なことですが、反面、その代償として、商業的に制限的なライセンスを持つライブラリー機能を置き換えるために、多くの人がコード・ライブラリーを書く羽目になったのです。

そうしたソフトウェア・ライブラリーの1つが、Sun Microsystems JavaMail APIです。Sunは、彼らのJavMail基準実装のために大量の作業を行いました。この実装には、インターネット上にある数多くの文書に記述されている機能が含まれています(こうした文書は、インターネットRFC(Requests For Comment)のネットワーク・メール・プロトコルの機能的な基本を記述しています)。私の見る限り、RFCは厳密にパブリック・ドメインであり、マゾヒズムの傾向を持つソフトウェア開発者が、今日のインターネットを駆動する数多くの下位レベルシステムに対して、詳細な動作モデルを作成することを許しているようです。Sun JavaMailソースコードは、直接、間接の商用使用を制限する、特別な研究ライセンスの下でダウンロードすることができます。これは明らかに、Apacheライセンスとは互換性がありません。その結果、恐らく無料で入手可能な唯一のJavaMail API実装がSunによって作成されたにもかかわらず、それをGeronimoで使うことはできないのです。Sunがこうした手法をとった理由は恐らく、誰かがJavMail基準実装を使って大儲けする事態を防ごうとしたため、というのが私の見方です。(この基準実装を作るためには、多くの開発者が、パブリック・ドメインのRFCを書き換えるために徹夜を続けたのです。)

これとは対照的に、Geronimoチームの努力は、誰にも共通に有益なものを目指していると思います。Geronimoチームでは、誰でも(つまり会社であっても)自由に使用できるオープン・ライセンスを持ったソフトウェア・プラットフォームを作り出すために、懸命な努力を続けています。このソフトウェア品質を高いまま維持できれば、非常に前向きに市場に受け入れられるでしょう。しかしそうした努力は、JavaMailのような製品に付加されたライセンス条件によって、妨害されています。JavaMailは、その起源からしてパブリック・ドメインであると思えるのですが、そうではないのです。

これはつまり、Geronimoが完全なパッケージを提供するためには、またも、一団となった人達が、パブリック・ドメインにあるインターネット・メールRFCを、実働ソフトウェア・モデルに書き換える必要があり、その後で、クリーンルーム版のSun JavaMail APIを書いて全部を貼り合わせる、という作業が必要なことを意味します。悲しいかな、これは真実なのです。そして、そうした作業は非常に複雑なものですが、完全な、そして汚れのない、ビジネスで使いやすいGeronimoアプリケーション・サーバーを実現するためには、やはり必要なのです。Javaライブラリーを .NETに移植する、とでも言うのでない限り、ソフトウェアは1度書きさえすれば努力を2度繰り返す必要がない、というのが理想ですが、現実の状況は理想からほど遠いのです。

では、Geronimoグループは、そのアプリケーション・サーバーと共にSun JavaMailバイナリーをなぜ再配布しないのでしょう。その部分のためのソースコードは、Sunから直接入手する以外、入手方法がないという事実の他に、Geronimoグループが再配布にこだわる理由は他にもあるのです。その理由の1つは、このAPIのソースコードのどの部分であっても、一部を置き換えたバイナリーを製品に入れて再配布することは、ライセンスで禁止されているのです。Geronimoは、Geronimo独自のJavaMail APIスタブを持つために、これを行っています(J2EE(Java 2 Platform, Enterprise Edition)認証を受けるために要求されているのです)。また、Sunのソフトウエア・ライセンス条件の中には、皆さんのソフトウェアに何らかの問題が起き、法廷闘争に巻き込まれた場合には、法廷においてSunを弁護することに同意する必要がある、という旨の文も含まれています。この文は非常に変則的に思えます。皆さんは彼らのライセンス条件の中で、彼らのソフトウェアの使用によって発生しうる、いかなる問題に対してもSunの責任を問わない、ということに既に同意しているのです。なぜ法廷闘争において、Sunを守ることにも責任を持たなければならないのでしょうか。Apacheライセンスでは、こうした種類のことは、何も言っていません(ただし、何らかの問題が起きた場合にソフトウェア所有者(ソフトウェアを書いた人)が責任を問われないようにしようとしています)。それで充分ではないでしょうか。ただし、私は法律家でありませんので注意してください。

この点に関して、(そして他の開発グループとは異なり)Geronimoグループは、ライセンス非互換という問題を避けることに十分な注意を払っており、純粋性を保証するためにライセンス問題が起きてくる状況を明確に避けています。彼らは、この戦いを続ける必要があります。今やバージョン1.0が入手できるため、多くの目がGeronimoに向けられるでしょう。そしてライセンスが非常に重要になるはずです。これまでの苦しい努力、つまりライセンスに注意し、ビジネスに使いやすいコードベースを維持しようとするための努力が、必ず報われるはずです。IBM WebSphere® Application Serverのコミュニティー版は、Geronimoに基づいています。これは、彼らの戦略が正しいものであること、大会社がGeronimoアーキテクチャーとそれをサポートするコミュニティーを信頼していること、そしてGeronimoが今後も長い間存続するであろうことを、明確に示しています。

夢から現実へ

私達は、将来のソフトウェア・インフラの第一階層が出現する予兆の光を見ているのでしょうか。残念ながら、私は法律家ではないと強調すると共に、私は将来を予測できない、ということも認めざるを得ません。しかし私は、現在のような、無数の分断されたグループが狂ったようにソフトウェア・アーキテクチャーの下位レイヤーを実装し直している、というソフトウェアの「島モデル(island model)」から、今後10年以内に卒業できることを強く望んでいます。そんなモデルではなく、どんなアプリケーションでも載せて統合できるような、堅牢でビジネス向きのコンポーネント・フレームワークが見られるようになって欲しいものです。私の意見では、Geronimoは、その実現を目指す最初の光であると思います。


ダウンロード可能なリソース


関連トピック


コメント

コメントを登録するにはサインインあるいは登録してください。

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=60
Zone=Open source, Java technology
ArticleID=232896
ArticleTitle=Geronimoへの転向: Geronimoについて、そしてApacheライセンスの苦闘と収穫
publish-date=01172006