最近、オープンソースのライセンスについて勉強している。以前からオープンソースソフトウェア（以下、OSS）の恩恵に預かっていたり、その世界や人に魅力を感じまくってはいたのだが、そのライセンス体系や、オープンソース自体の定義について、これまでほとんどまともな理解をしてこなかったことを、今さらながら痛感している。今日は、「オープンソースの定義」について、知ったことをまとめておく。正直言ってよく分からなかった部分も中にはあるので、突っ込み歓迎の意を表しておく。
「オープンソースの定義」の生い立ち
今日で言う「オープンソース」を定義したのは、ブルース・ペレンスという人物である。彼はその後、非営利団体であるオープンソース・イニシアティブ（OSI）を設立した。ここで言う「オープンソースの定義（The Open Source Definition…以下、OSD）」とは、彼の書いた"The Open Source Definition"である。原文はここ、八田真行氏による日本語訳はここで読むことができる。この記事では、日本語訳版の文章を逐次引用しつつ、解釈を進めていこう。
全10項目があるのだが、ちょっと僕の足りない知識では分かりにくい部分があり、咀嚼するのに時間がかかってしまった。なんとか理解できたような気がするので、それを忘れないようにメモしておきたい。また、文章がややこしいのが分かりにくい原因なのではないかと思うので、できるだけ各項目について要点を箇条書きでまとめていくことを試みたい。
以下の項目
多いので、いったんここで項目を挙げておく。
- 再頒布の自由
- ソースコード
- 派生ソフトウェア
- 作者のソースコードの完全性（Integrity）
- 個人やグループに対する差別の禁止
- 利用する分野に対する差別の禁止
- ライセンスの分配（distribution）
- 特定製品でのみ有効なライセンスの禁止
- 他のソフトウェアを制限するライセンスの禁止
- ライセンスは技術中立的でなければならない
一つずつ見ていこう。
※なお、日本語訳を見ると、各項目に「理由：～」という文章が書いてある。この記事では基本的に各項目の解釈に焦点を絞っているが、項目についての理解が進んだ後は、ぜひ「理由」を読んでおいてほしい。
再頒布の自由
「オープンソース」であるライセンス(以下「ライセンス」と略)は、出自の様々なプログラムを集めたソフトウェア頒布物(ディストリビューション)の一部として、ソフトウェアを販売あるいは無料で頒布することを制限してはなりません。ライセンスは、このような販売に関して印税その他の報酬を要求してはなりません。
「『オープンソース』であるライセンスは（略）販売あるいは無料で頒布することを制限してはなりません。（略）印税その他の報酬を要求してはなりません。」とある。
箇条書きにすれば、
- オープンソースライセンスは
- 再頒布時に、無料か有料で販売するかは、利用者の自由にすること
- もし利用者が販売することを選んだ場合でも、報酬や印税を求めないこと
こうだ。言い換えると、
- OSSの利用者は、そのOSSを利用して作ったものを
- 無料で再頒布してもOKだし
- 売ってもOK
- そのとき、利用者はもとのOSS（の作者）に対して
- 報酬とか印税を支払う必要はない
こういうことになる。
ソースコード
「オープンソース」であるプログラムはソースコードを含んでいなければならず、コンパイル済形式と同様にソースコードでの頒布も許可されていなければなりません。何らかの事情でソースコードと共に頒布しない場合には、ソースコードを複製に要するコストとして妥当な額程度の費用で入手できる方法を用意し、それをはっきりと公表しなければなりません。方法として好ましいのはインターネットを通じての無料ダウンロードです。ソースコードは、プログラマがプログラム を変更しやすい形態でなければなりません。意図的 にソースコードを分かりにくくすることは許されませんし、プリプロセッサや変換プログラムの出力のような中間形式は認められません。
文章は長いが、言っていることは簡単だ。
- OSSは、そのソースコードを頒布していなければならない
- コンパイル済みのバイナリファイル（たとえば.exeファイルとかの）形式で頒布している場合も、ソースコードを一緒に頒布すべし
- もしバイナリファイルとソースコードを一緒に頒布できないとしても、簡単にソースコードが入手できるようにしておくこと
- できればインターネットで公開して、無料ダウンロードできるようにしておくこと
- ソースコードは、プログラマが改変しやすいようにしておくこと
- ソースコードを中間形式で配布するのはダメ。要するにテキスト形式で、ちゃんと人間がいじれる状態で配布すること
とにかく、テキスト状態のソースコードをちゃんとオープンにしておけということだ。分かりやすい。
派生ソフトウェア
ライセンスは、ソフトウェアの変更と派生ソフトウェアの作成、並びに派生ソフトウェアを元のソフトウェアと同じライセンスの下で頒布することを許可しなければなりません。
「～と同じライセンスの下で頒布することを許可しなければなりません。」あたりの言い回しが多少分かりにくく感じた。要するに、
- あるOSSの利用者は、
- そのOSSの内容を変更してもよい
- そのOSSを元にした、いわば「派生ソフトウェア」を新たに開発してもよい
- その派生ソフトウェアの頒布時に、
- 元のOSSと同じライセンスを適用してもよい
- 元のOSSと違うライセンスを適用してもよい
ということだ。
最後の、「元のOSSと違うライセンスを適用してもよい」のくだりが、一見すると原文に含まれていないような感じがしてややこしい。
作者のソースコードの完全性(integrity)
バイナリ構築の際にプログラムを変更するため、ソースコードと一緒に「パッチファイル」を頒布することを認める場合に限り、ライセン スによって変更されたソースコードの頒布を制限することができます。ライセンスは、変更されたソースコードから構築されたソフトウェアの頒布を明確に許可していなければなりませんが、派生ソフトウェアに元のソフトウェアとは異なる名前やバージョン番号をつけるよう義務付けるのは構いません。
10項目中、最も分かりにくいと思う。箇条書きで内容をまとめられるのか心配である。
まず、この項目は、「派生ソフトウェア」の再頒布時の形態について、二つのケースを想定している。すなわち、
- あるOSSのソースコード + その利用者が作ったパッチファイル
- あるOSSのソースコードを、その利用者が改変したもの
の2パターンである。では、一つ目のケースから見ていこう。
「1. あるOSSのソースコード + その利用者が作ったパッチファイル」の場合について、
- あるOSSのライセンスは、
- 元のOSSのソースコードを変更した状態で再頒布することを禁止してもよい
- ただし、同時に「パッチファイル」を頒布することを認めなければならない
ということが書かれている。
ここで「？！」となるのが、「元のOSSのソースコードを変更した状態で再頒布することを禁止してもよい」というくだりではないだろうか。これが、前項である「派生ソフトウェア」で定義されていた「そのOSSの内容を変更してもよい」という内容と相反するように感じられるのが、個人的にはOSDややこしポイント第一位である。
この項を理解するには、まず「パッチファイル」について知っていなければならない。かいつまんで言えば、パッチファイルとは、「ソースコードの『変更点』をまとめたファイル」である。「変更点」とは、たとえば「○行目を削除」とか「△行目の"public"という単語を"private"に変更」とか、文字通りソースコードを変更する内容である。
このパッチファイルを、元のソースコードに「適用」することによって、パッチファイルにまとめられた「変更点」の情報がソースコードに一気に反映される。
つまり、「あるOSSのソースコード + その利用者が作ったパッチファイル」が一緒に頒布された場合、それを手に入れた第三者は、「あるOSSのソースコード」に「その利用者が作ったパッチファイル」を「適用」することによって、結果的に「その利用者が開発した派生ソフトウェア」を得ることができるわけだ（書いててもややこしい）。
なんでこんな面倒なことをわざわざするかというと、こうすることによって、「元のOSSの作者が書いたソースコード」自体はそのまま再頒布されるため、「元の作者のソースコード」と「派生ソフトウェアの作者が書いた変更点」とが明確にできるからである。作者や場合によっては、「自分はここまで書いたんだ」ということをはっきりさせておきたいかも知れない。そのための項目といえる。
では次に、「2. あるOSSのソースコードを、その利用者が改変したもの」の場合を見てみよう。
- あるOSSのライセンスは、
- （パッチファイルでなく）ソースコード自体を改変した「派生ソフトウェア」の再頒布を許可すべし
- その再頒布時に、「派生ソフトウェア」には元のソフトウェアとは違う名前、違うバージョンをつけることを強制してもよい
となる。
これは、「元のOSS」と「派生ソフトウェア」の名前やバージョンをしっかり区別させることによって、「元のOSSの作者が書いたソースコード」を明確にしておくためである。たとえば、あるOSSの作者が、そのOSSの「派生ソフトウェア」には「元のOSS」とは違う名前をつけるように強制することで、その二つが明確に違うものであり、「自分が書いたのは『元のOSS』のソースコードだ」と主張しやすくなるわけだ。
この2つのケースに共通するのは、どちらも
- オリジナルな作者が書いた範囲（ソースコード）を、明確に分かるようにする
ために定義されているということだ。これが、「作者のソースコードの完全性（integrity）」ということである。
個人やグループに対する差別の禁止
ライセンスは特定の個人やグループを差別してはなりません。
これは大変わかりやすい。言葉どおりなので、詳しい説明は不要だろう。なお、OSD日本語訳のこの項目に添えられた「理由」には、
進化の過程から最大の恩恵を引き出すためには、可能な 限り多種多様な人々やグループに、平等にオープンソースに貢献する資格が与 えられている必要があります。そこで、オープンソースなライセンスによって 誰かを進化の過程から締め出すことは禁止されています。
（後略）
と書かれている。個人的には、これこそオープンソースの思想であると思う。
利用する分野(fields of endeavor)に対する差別の禁止
ライセンスはある特定の分野でプログラムを使うことを制限してはなりま せん。 例えば、プログラムの企業での使用や、遺伝子研究の分野での使用を制限してはなりません。
これも、その言葉どおりだ。あえて言い換えるなら、
- このOSSをどんな分野で使ってもいいよ
- でも、うまくいかなくっても泣かないでね＞＜
ということだろうか。
ライセンスの分配(distribution）
プログラムに付随する権利はそのプログラムが再頒布された者全てに等しく認められなければならず、彼らが何らかの追加的ライセンスに同意することを必要としてはなりません。
これまでの項目において、「再頒布」とは「あるOSSに何らかの改変を加えた派生ソフトウェアを頒布すること」という意味で述べることが多かった。しかし、ここで言う「再頒布」とは、特に「あるOSSを入手した後、そのままの形で（改変を加えず）他の人に頒布すること」と考えればよい。
- あるOSSが、あるライセンスの下で頒布された場合
- そのOSSを、そのまま再頒布するとき、ライセンスを変更してはならない
ということである。
特定製品でのみ有効なライセンスの禁止
プログラムに付与された権利は、それがある特定のソフトウェア頒布物の一部であるということに依存するものであってはなりません。プログラムをその頒布物 から取り出したとしても、そのプログラム自身のライセンスの範囲内で使用あるいは頒布される限り、プログラムが再頒布される全ての人々が、元のソフトウェア頒布物において与えられていた権利と同等の権利を有することを保証しなければなりません。
これも、言い回しが難しい気がするが、意味はそう難しいものではない。ここでいう「プログラムに付与された権利」とは、「OSSのライセンスの内容」である。それが「ある特定のソフトウェア頒布物の一部であるということに依存するものであってはならない」。つまり、
- 「あるソフトウェアの一部である場合のみ、OSSとしてのライセンスが有効になるよ」はNG
- そのOSSが「あるソフトウェア」の一部であろうがなかろうが、OSSとしてのライセンスは絶えず有効である
ということである。
この定義によって、たとえば「ある特定の商用ソフトウェア"A"」に「あるOSS"B"」が含まれていた場合（それ自体は悪いことではない）、「商用ソフト"A"の一部として"B"を入手した場合のみ、あなたは"B"をOSSとして利用できますよ。魅力的でしょう。だから"A"を買ってください。」という行為を防ぐことができる。
他のソフトウェアを制限するライセンスの禁止
ライセンスはそのソフトウェアと共に頒布される他のソフトウェアに制限を設けてはなりません。例えば、ライセンスは同じ媒体で頒布される他のプログラムが全てオープンソースソフトウェアであることを要求してはなりません。
- OSSライセンスは、
- どんなソフトウェアと一緒に頒布するかは、頒布者の自由にすべし
- たとえば、「このソフトウェアは、一緒に頒布されるソフトウェアがすべてOSSである場合のみ、OSSとして利用してよい」とかはNG
一緒に頒布される他のソフトウェアがOSSだろうとプロプライエタリだろうと関係ない。それらに依存した内容をライセンスに盛り込んではならない、ということだ。
ライセンスは技術中立的でなければならない
ライセンス中に、特定の技術やインターフェースの様式に強く依存するような規定があってはなりません。
これは、読んだ当初は例えば「このソフトウェアは、Linux上で動作する場合のみOSSとなる」とかいった規定を禁止するものがと思った。今でも、文章のみを見るとそう思う。だが、OSD日本語訳の「理由」を見てみると、どうもそれとは少し違ったニュアンスのことを想定しているようだ。
理由: この規定で特に念頭に置いているのは、ライセンサーとライセンシーの間で 契約を成立させるために明示的な同意の意思表示を必要とするような ライセンスです。いわゆる「クリックラップ(click-wrap)」を要求する規定は、 ソフトウェア頒布において重要な手法であるFTPダウンロードや CD-ROM アンソロジー、ウェブのミラーリングなどと衝突する可能性がありますので、 このような規定もコードの再利用を妨げてしまいます。よって、本定義に 準拠するライセンスは、(a) ソフトウェアの再頒布が、ダウンロード時の クリックラップをサポートしないようなウェブ以外の経路で起こりうるという 可能性 (b) ライセンスで保護されるコード (あるいは保護されるコードの 再利用された部分) はポップアップダイアログをサポートできない非GUIの 環境でも実行されれうるという可能性、を認めなければなりません。
つまり、OSSを利用する際に、利用者が利用許諾の内容について間違いなく同意の意思を表示できるようにするための規定ということである。箇条書きにしてみよう。
- OSSを利用するとき、以下のような場合についても、利用者がライセンスの内容に同意を示せるようにすべし
- 例えば、GUI環境がなくて、「同意しますか？はい/いいえ」といったポップアップが出せない場合
- 例えば、Webからのダウンロード、CD-ROM等の媒体等々、複数の手段で頒布される場合
特に二つ目、「複数の手段で頒布される場合」が面白い。これは、例えば「Webからダウンロードしたことを以って同意したとみなす」とか、「パッケージの包装を破ったことをもって同意したとみなす」など（こういった利用許諾確認をクリップクラップという）、ライセンスの中で利用意思の確認手段を特定してしまうと、それだけOSS再頒布/再利用のチャンスを制限してしまうことになる。だから、特定の媒体やインターフェース環境下でのみ正常に利用意思が確認されるようなライセンスであってはならない。と、いうことのようだ。
ふう、やっと終わった。
これは数ある具体的なライセンスの大枠
以上で、OSD10項目の解釈を終える。しかしこの10項目は、具体的なライセンス（GPLとかBSDとか）の基礎となるものに過ぎない。各ライセンスは、このOSDに反しない中で、また独自に種々の取り決めを行っている。いわば、OSDは日本国憲法、各ライセンスは法律のようなものだろうか。いや、違うか。
とにかく、今回これをまとめたことによって、OSDの概要はつかめたように思う。今後は、各ライセンスについて、その内容や特徴、違いを勉強していきたい。
21:26:00
