PR

オープンソースの定義をひも解く

 そもそもオープンソースに関して議論するためには,その意味を知らなければならない。オープンソースの定義自体を分析してみよう。

 オープンソースの定義は,平易に見えてその個々の条件が意味するところ,「なぜそのような条件が置かれるのか」をつかむのは案外難しい。また,GNU GPL(General Public License)やその他,かなり性質の異なる諸ライセンスをひとくくりにするため,微妙な言い回しをあえてしている部分もある。以下では,筆者の訳をベースに,具体的にその条項がどういう意味を持っているのか追ってみるが,可能な限り原文*にも当たってみていただきたい。念頭に置くべきなのは,こういった諸条件がバザール開発においてどのような意味を持つのかということ,そして「普及は善」という価値観である。ソフトウェアが普及すればするほど,バザール開発が成功しやすくなるからだ。

はじめに

 「オープンソース」とは,単にソースコードが入手できるということだけを意味するのではありません。オープンソースであるプログラムの頒布条件は,以下の基準を満たしていなければなりません。

*      *      *

 先に書いたとおり,オープンソースは単にソースコードがオープン(公開)されていて,手に入るということだけを意味するのではない。それだけでは,著作権の扱いについて何も指定されておらず,頒布も改変もできないからだ。頒布や改変が明示的に許可されていることは,バザール開発の前提条件である。

1. 再頒布の自由

 オープンソースであるライセンス(以下,ライセンスと略)は,出自のさまざまなプログラムを集めたソフトウェア頒布物(ディストリビューション)の一部として,ソフトウェアを販売あるいは無料で頒布することを制限してはなりません。ライセンスは,このような販売に関して印税その他の報酬を要求してはなりません。

*      *      *

 オープンソースの定義に,一つの柱としてDebianプロジェクトのようなディストリビュータの視点が盛り込まれていることは先に述べた。ここでの再頒布の自由は,頒布コストを下げるという点で特に重要である。作者にしろ,利用者にしろ,自分の著作物をコントロールしたいというエゴがある。その両方の性質を持つディストリビュータがこの定義を定めたということが,オープンソースのバランス感覚に大きく貢献していると言えよう。

2. ソースコード

 オープンソースであるプログラムはソースコードを含んでいなければならず ,コンパイル済形式と同様にソースコードでの頒布も許可されていなければなりません。何らかの事情でソースコードと共に頒布しない場合には,ソースコードの複製に要するコストとして妥当な額程度の費用で入手できる方法を用意し,それをはっきりと公表しなければなりません。方法として好ましいのはインターネットを通じての無料ダウンロードです。ソースコードは,プログラマがプログラムを変更しやすい形態でなければなりません。意図的にソースコードを分かりにくくすることは許されませんし,プリプロセッサや変換プログラムの出力のような中間形式は認められません。

*      *      *

 ソースコードの頒布に関する条件である。バイナリだけ転がっていてもオープンソースにとってはあまり意味がない。また,例えばソースコードは入手できるが高額な手数料が必要,あるいはややこしい手続きを踏まないと入手(ないし閲覧)できない,または非常に可読性の低い形式でのみ提供されるなど,さまざまな隠蔽工作がとられる可能性があるが,それらをここで排除している。こういった工作はバザール開発の円滑な進行を阻害する。

3. 派生ソフトウェア

 ライセンスは,ソフトウェアの変更と派生ソフトウェアの作成,並びに派生ソフトウェアを元のソフトウェアと同じライセンスの下で頒布することを許可しなければなりません。

*      *      *

 これは改変の自由を定めたものだが,見た目以上に重要な意味がある。というのも,この条項が存在することによって,オープンソース・ソフトウェアは,「分岐」(fork)の自由が保障されていることになるからだ。

 ソフトウェアの開発者が皆有能とは限らないし,優れたソフトウェアにもかかわらず,プロジェクトを管理運営している主体が好ましくないということがある。また,管理者がプロジェクトに関心を失う(企業が主体の場合は倒産する)など,いつの間にかプロジェクトが中断してしまう場合も少なくない。そういった場合,開発プロジェクトを分岐させ,自分が先頭に立って開発を続行するという選択肢がここで常に保証されているわけだ。もちろん開発フォースが分散するというデメリットもあるわけだが,オープンソース・ソフトウェアのプロジェクトが易々と立ち枯れしないのはこの条項の存在によるところが大きい。

4. 作者のソースコードの 完全性(integrity)

 バイナリ構築の際にプログラムを変更するため,ソースコードと一緒に「パッチ・ファイル」を頒布することを認める場合に限り,ライセンスによって変更されたソースコードの頒布を制限することができます。ライセンスは,変更されたソースコードから構築されたソフトウェアの頒布を明確に許可していなければなりませんが,派生ソフトウェアに元のソフトウェアとは異なる名前やバージョン番号を付けるよう義務付けるのは構いません。

*      *      *

 これは結局妥協の産物である。現在も高い人気を誇るデスクトップ環境KDEは,ノルウェーTrollTech社の「Qtライブラリ」を利用しているが,このライブラリに適用されているライセンスのQPL(Q Public License)はパッチによる改変のみを許可していた。そして,Qtをオープンソースのカテゴリから排除するのは益よりも害が大きいと判断されたのである。とはいえ,パッチでの改変は許可されているわけで,頒布者から見れば実際上それほど大きな問題にはならない。

 このように実害がないと判断されれば,QPLのような癖のあるライセンスもオープンソースに含められるように定義のほうが配慮するのである。逆に言うと,自分のライセンスに特殊な条項(たとえば平和利用以外禁止)が含まれていて,それが認められないのが納得できないなら,その実益を主張して定義の改訂を申し出るべきだと筆者は思う。繰り返しになるが,オープンソースの定義は絶対のものではない。実際に数回にわたって改訂されているし,本条項のような妥協が入る余地もあるのである。

5. 個人やグループに対する差別の禁止

 ライセンスは特定の個人やグループを差別してはなりません。

*      *      *

 例えば兵器産業での利用を禁ずるというライセンスは,なかなか立派なもののように見えるが,実際のところ「兵器産業」の定義は難しい。また,暗号技術などには輸出制限がかかっている国々があるが,そういった国での利用を個々のソフトウェアで禁止しても,情勢が代わればすべてのソフトウェアのライセンスを変更しなければならなくなる。そもそも,この種のことを気にするのは善意の頒布者だけで,悪用したい人間はライセンスなど無視するものだ。頒布者がこういった主観的要素が入る問題を判断するのはかなり困難なので,排除する必要がある。オープンソースの定義の一つの目標は,あるライセンスが「十分フリー」であるかどうかを簡単に見極めるということなので,この種の条件を置くことが必要となってくるわけだ。

6. 利用する分野(fields of endeavor)に 対する差別の禁止

 ライセンスはある特定の分野でプログラムを使うことを制限してはなりません。例えば,プログラムの企業での使用や,遺伝子研究の分野での使用を制限してはなりません。

*      *      *

 相手が気にくわないからといって利用を禁止してはならない。また,MS-DOS全盛期にポピュラーだったいわゆるフリーウェアの中には,商用利用を禁止しているものが多かったが,ここではそういったものを排除している。オープンソースがビジネス寄りだと言われる一つの根拠だが,実のところ,GNU GPLでも商用利用を禁止しているわけではない。自明なことを明記しただけとも言えよう。

7. ライセンスの分配(distribution)

 プログラムに付随する権利はそのプログラムが再頒布された者すべてに等しく認められなければならず,彼らが何らかの追加的ライセンスに同意することを必要としてはなりません。

* * *

 ライセンス自体はDFSGに準拠しているが,そのライセンスが有効になるためには機密保持契約(NDA)にサインする必要がある,というような微妙な手段によって実質的に利用を制限しようとする動きを排除するのがこの条項だ。

8. 特定製品でのみ有効な ライセンスの禁止

 プログラムに付与された権利は,それがある特定のソフトウェア頒布物の一部であるということに依存するものであってはなりません。プログラムをその頒布物から取り出したとしても,そのプログラム自身のライセンスの範囲内で使用あるいは頒布される限り,プログラムが再頒布されるすべての人々が,元のソフトウェア頒布物において与えられていた権利と同等の権利を有することを保証しなければなりません。

*      *      *

 あるディストリビューションでのみフリーなソフトウェアや,GNU/Linux上で利用する分にはフリーだが,Windowsに移植したものはフリーではない,といったようなものがここで排除される。普及の促進という見地から重要だ。

9. 他のソフトウェアを制限する ライセンスの禁止

 ライセンスはそのソフトウェアと共に頒布される他のソフトウェアに制限を設けてはなりません。例えば,ライセンスは同じ媒体で頒布される他のプログラムがすべてオープンソース・ソフトウェアであることを要求してはなりません。

*      *      *

 自作のソフトウェア以外もすべてオープンソースであることを要求するというのはうまい考えのように見えるかもしれない。

 しかし,各ディストリビュータが独自性を出すときに,フリーではないフォントを追加するというようなことをできなくするのは,益より害のほうが大きい。

10. ライセンスは技術中立的 でなければならない

 ライセンスの条項で,技術やインタフェースの様式を断定してはなりません。

*      *      *

 比較的最近加えられたものだが,ライセンスにおいて「URL」など特定の技術に依存した言い回しをすることを禁止している。10年も経てば,今私たちがURLとして知っているものも時代遅れとなって存在しない可能性があるからだ。

 このように,主に頒布者の観点から「どこまでがライセンスによる制限として認められるのか」を徹底的に検討し,かつできるだけ多くの既存のライセンスをカバーするという困難な条件を達成したのがオープンソースの定義である。つまりライセンスがどういう条件を満たしていれば,バザール開発が円滑に運ぶかを考え抜いた条件なのだ。ゆえに,これを逸脱してオープンソースを名乗るのはおかしいし,またオープンソースのメリットを期待するのも難しいと言えるだろう。


むすび

 今回はあえて論争的な書き方をしてみた。皆さんからの異論・反論を期待したい。というのは,筆者はオープンソースの定義に関して,もっと実質的な議論が必要だと考えているからだ。オープンソースの定義は絶対でも不変でもないし,誰かのためにあるのでもない。あなたのためにあるのである。ぜひオープンソースの定義や代表的なオープンソースのライセンスをじっくりと読み,その条項の一つひとつが自分のやりたいことに対してどういう意味を持つのか,慎重に検討してみていただきたい。

八田 真行 Masayuki Hatta

Debian Project Official Developer
GNU Project Translation Coordinator, Webmaster
1979年生まれ。Debian GNU/Linux公式開発者の傍ら,GNUプロジェクトの翻訳コーディネータを務める。GNU GPLやオープンソースの正式な定義である「The Open Source Definition」の日本語訳を公開。東京大学大学院経済学研究科に在籍中。