連載
» 2008年03月26日 00時00分 UPDATE

まつもとゆきひろのハッカーズライフ:第13回 プロジェクトの障害 (1/2)

オープンソースプロジェクトを開始するとして、そのソフトウェアに設定するライセンスとして何を選んだらよいでしょうか。今回はライセンスというものについて考えてみましょう。

[Yukihiro“Matz”Matsumoto,ITmedia]

プロジェクトの障害

 2007年6月、15年ぶりにGPLの新版(v3)が公開されました。具体的な内容はともかく、フリーソフトウェア/オープンソースのライセンスが再び注目されています。今回はライセンスというものについて考えてみましょう。

 世の中にハッカー気質を持つ人はたくさんいますが、その数だけオープンソースプロジェクトが存在するかというと、なかなかそうはいきません。「自分でオープンソースプロジェクトを始める」のはハードルが高く、さまざまな障害があるわけですが、オープンソースプロジェクトにおける非技術的な障害の筆頭はライセンスでしょう。ほかの問題の多くは、そもそも根源的な問題である「何を作るのかを決める」とか、「実装手段を考える」あるいは「デバッグする」に至るまで、ある程度「ハッカー魂」を揺さぶるものがあります。だからこそ、ハッカーたちは喜んでプロジェクトに参加するわけです。

 ところが、ライセンスときたら、プログラムほど明確ではないし、技術的にも面白くもないし、その割りには厳密な話をし始めると面倒で、煮ても焼いてもおいしくありません。いっそ「こんなものなければよいのに」と思うほどです。では、なぜわざわざライセンスを用意するのかというと、主な理由は意思表明のためです。適切なライセンスには、「開発者がこのソフトウェアをどう扱ってほしいのか」という意思をはっきり示すことになります。それによって、ユーザーは安心してソフトウェアを使うことができるわけです。これが不明瞭な場合、ユーザーが確実に安心してソフトウェアを利用するには、開発者に対して直接問い合わせるしかありません。世界中から「こんなケースに使ってもよいか?」と問い合わせが殺到するのは、決してうれしいことではありません。また、ライセンスには、訴訟など法的なトラブルから守られる(かもしれない)という期待も込められています。

ライセンスの選び方

 オープンソースプロジェクトを開始するとして、そのソフトウェアに設定するライセンスとして何を選んだらよいでしょうか。

 わたしからできる最初のアドバイスは、「決して新しいライセンスを作らない」です。Rubyの開発を開始した時点でそのことが分かっていれば、わたしの人生はもうちょっとだけ楽だったでしょう。当時のわたしは、ソースコードの流用を明示的に許可したライセンスを提供したいと考えていました。そこで、Perlのライセンス(Artisticライセンス*)をベースに流用を許可し、入出力データ(Rubyの場合はRubyプログラム)には制限がおよばないことを明記したライセンスを用意しました。ライセンスを作るのは、プログラミングに少し似ています。何を許可したいとか、何を禁止したいとか考えるのはアルゴリズムのときと同じです。思い返せば、確かに作っていたときは楽しかったんです。

 しかし、この「コード」はプログラムよりもずっとデバッグが大変です。プログラムほど簡単に「実行」できないので、問題はすぐに発見されませんし、例え見つかっても簡単には修正できません。

 例えば、自分で作ったライセンスに含んだ条項に何らかの問題があったとしましょう。すぐに思いつくのは、GPLと互換性がなく、GPLソフトウェアとリンクできなくなってしまうケースです。「似たような思想に基づいて作られたライセンス同士が非互換とは、いったいどういうことか」と悲しくなりますが、これがライセンスの現実です。その場合には、(困るユーザーもいることでしょうが)GPLソフトウェアとのリンクをあきらめるか、あるいはライセンスの変更を行うことになります。

 このとき、ライセンスを適用するソフトウェアの全コードが1人によって書かれたものであれば、問題はほとんどありません。新しいバージョンを新しいライセンスでリリースすればそれでおしまいです。しかし、例えば別の人のパッチが含まれていれば、ソフトウェアはあなただけのものではなく、法的にはパッチを書いた人との共同著作物という扱いを受けます。厳密な話をすると、他人の権利を勝手に侵害するわけにはいきませんから、理論上ライセンスの変更にはこれら共同著作者すべての合意が必要です。何年もの間、開発を行ってきたRubyのようなソフトウェアでは、権利関係者が何人いるのかすでに確認しようがありません。FSF(Free Software Foundation)のソフトウェアのように、コードを貢献する場合には権利譲渡契約を結ぶようにしているなら楽なんでしょうが、パッチをもらうたびにそのような手続きを行うのも面倒です。たいていの場合は、ライセンスの変更をあきらめてしまうか、さんざん努力しても結局は全員の確認を取れず、誰かから苦情が出ないことを祈りつつ変更することになります。

 自分でライセンスを作る行為は、そのような苦労を何年にもわたって一手に引き受けることを意味するのです。心からアドバイスします。止めた方が無難です。

このページで出てきた専門用語

Artisticライセンス

Perlのライセンスは、このArtisticとGPLの二本立て。Larryが自分の意見を表明したもので、FSFからは単体では「フリーソフトウェアライセンスではない」とまで言われている。これをベースにしたことが、Rubyライセンスの不幸の始まりというか何というか。


       1|2 次のページへ

Copyright© 2016 ITmedia, Inc. All Rights Reserved.

Loading

ピックアップコンテンツ

- PR -

注目のテーマ

マーケット解説

- PR -