オープンソースとは何か？ Open Source Definition逐条解説書

オープンソースとは何か？
Open Source Definition(オープンソースの定義) 逐条解説書
v1.0, 2024年1月22日
佐渡秀治 Open Source guy

オープンソース(Open Source)とは、米国の公益法人であるOpen Source Initiative(OSI)が策定した「オープンソースの定義」(Open Source Definition)で書かれた条件を満たすライセンス及びそのライセンスが適用されるソフトウェアのことである。このオープンソースという用語は自由ソフトウェア(Free Software)の代替として企図され、広く一般へ自由なソフトウェアを広めるためのキャンペーンのための用語として人為的に策定されたが、その後のオープンソース・ムーブメントと呼ばれる熱狂期を経て、紆余曲折ありながらも現在では世界の様々な領域においてオープンソースは当たり前の存在となっている。

しかしながら、オープンソースという用語の誕生から四半世紀以上の時間が経過し、巨大化したエコシステムの中においてこの用語が指す意味の範囲を意図的あるいは意図せずに拡大解釈しようとする動きが散見されるようになった。また、そもそもオープンソースという言葉の意味を理解しないままにオープンソースの状態にあるソースコードの利用行為を行うことも珍しいことではなくなってきている。

そこで本稿では、技術者から法務の実務者まで幅広くオープンソースに関する理解を深められるようオープンソースの根幹である「オープンソースの定義」を逐条的に解説していく。逐条解説を名乗りながらもこの文書を持って完全な法的な解釈とできるものでは全くないのではあるが、オープンソースへの根本的な理解に迫る文書は日本国内において特に存在しないという現状を踏まえ、少なくとも長い歴史を見てきた者の知見を見せていくことが重要なのだろうと考えるに至り、本稿を執筆することにした次第である。

なお、本稿においては、八田真行(mhatta)による「オープンソースの定義」の日本語訳に基づいて解説を行う。

0. Introduction(はじめに)

オープンソースの定義は十箇条で構成される簡潔な文書であるが、本稿ではこの定義の一条毎に章立てし、必要であれば一つのセンテンス単位で解説を加えるという体裁で進めていくこととする。まず、最初の0章は十箇条の前に記述されている一般的にはほぼ見過ごされるパラグラフからの解説である。

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

短い二つのセンテンスで構成される定義本体の前文にあたる文章である。特に思想性のようなものはなく、基本的にはこれから続く文章がオープンソースであるための条件と述べているに過ぎない。この思想性の弱さ、そしてある意味で単なる条件に徹したことがオープンソースの隆盛に繋がったとも考えられるが、この短いパラグラフにも幾つか大きな意味が潜んでいる。

起源からこれを説明すると、オープンソースの定義はDebianフリーソフトウェア・ガイドライン (DFSG)を流用したものであり、固有名詞を変更した程度の差異しかないが、さらにそのDFSG自身はDebian社会契約という文書の一部でしかない。Debian社会契約は自由ソフトウェアのコミュニティに対してDebianプロジェクトとしての誓約事項をまとめた規範であるが、つまり、Debian社会契約にはDebianとしての思想、哲学が詰まっているものの、DFSGの部分はその社会契約の対象となる自由ソフトウェアとは何か？という範囲を指し示しているだけの役割を果たす。よって、DFSGには思想性や哲学性といったものが反映される文言が入る余地は比較的少ない。

ということで、DFSGは単に条件だけを並べているのでそれをそのまま流用すればオープンソースの定義には条件の部分しか存在しないはずだが、このIntroduction(はじめに)の部分の二つのセンテンスだけはDFSGに全く存在しないものであり、何故かオープンソースの定義の策定時に新規で書き加えられているのである。

0.1. 第一センテンス

文書全体の最初となるこのセンテンスは、ソースコードが入手できることだけがオープンソースの条件ではないとしている。このパラグラフ以降にソースコード入手性等の条件が書かれているわけなのでわざわざ冒頭で触れる必要はないのだが、この敢えて書いたということにこのセンテンスを書き加えた定義の作者であるBruce Perensの想いが反映されていると推測できる。

今では自由ソフトウェアと日本語へ訳されることが示すようにFree SoftwareのFreeは自由であり、無料の意味ではない。このFreeという単語の意味の誤解を払拭することはオープンソースという用語をわざわざ作り出すことになった一つの理由であったわけだが、当然ながらOpen Sourceというごく一般的な二語の単語から構成される用語には誤解が発生する余地はあるだろう。そのようにBruce Perensが考えたのかどうかは定かではないが、Open Sourceという二つの単語で想像しやすいソースコードの入手性以外の条件も存在することを先ず最初に示すという効果があったと考えられる。

ともかく、先ず最初にソースコードの入手性以外の条件の存在を示すことで、それらの他の条件の重要性を際立たせているとも言えるだろう。

0.2. 第二センテンス

一見、第二センテンスは単に以降の条件を全て満たすことがオープンソースであるための条件と示しているだけに見える。実際その通りなのであるが、ここで注目すべきは「オープンソースであるための条件は」ではなく、「オープンソースであるプログラムの頒布条件(distribution terms)は」という少し回りくどい言葉を使用している所である。

頒布条件という言葉の意味する所は、通常のオープンソースのソフトウェアであればライセンスのことである。つまり、頒布条件という用語はライセンスと置き換えても良いということになるはずであるが、敢えてここで頒布条件としていることに意味が隠されているように見えてくる。

頒布条件という言葉が示す範囲はライセンスよりも当然ながら幅広い。オープンソースの文脈においてのライセンスは著作権を主体とする知的財産権の利用許諾であり、実務上はライセンス契約とは区別されているが、このような契約の範疇に入る行為や状態も策定時に念頭にあったのかもしれない。1998年当時、ソフトウェアの開発コミュニティの中においては著作権に基づいた利用許諾を予め行うという慣行があることはとうの昔に認識されていたが、それがグローバルで法的な効力を持つという認識が広く共有できていたかと問われると正直心許ない。少なくともライセンス契約論が度々出てくる中、狭義のライセンスという用語の範疇を超える意味を持たせたかったのかもしれない。

また、この観点であれば、パブリックドメインの存在も気にしていた可能性も考えられるだろう。パブリックドメインには著作権は発生しておらず、従って著作権の利用許諾を意味するライセンスとは明確に区別される。とは言え、パブリックドメインも誰もが自由に利用できることに変わりなく、これを暗黙のうちに定義の範囲に収めてしまいたいという意識があったとも推測は可能だろう。

つまり、頒布条件という用語にはライセンス以外の法的条件や状態までを含めたい意図が当初はあったのかもしれない。ただし、定義本体となる各条項においては頒布条件とは表記されず、ライセンスという用語が使用されているため、事実上オープンソースの定義はライセンスという法的条件を扱う形態だけに限られている。これによって基本的にはパブリックドメインもオープンソースではないということなる。このため、このセンテンスにおいて頒布条件と表現されることによる拡大的な解釈はその後に否定されているので意味をなさないのであるが、ここでの頒布条件という用語の使用は何らかの迷いの反映だったとすれば、それも歴史の綾というものだろう。

なお、このセンテンスで分かることは、オープンソースという用語が指す対象物が何であるか？ということが曖昧にされていることである。自由ソフトウェアが自由なソフトウェアを指すのは自明であるが、オープンソースの定義は一見するとライセンスを指しているように見える。しかし、ソフトウェアを指すように解釈することも可能である。この疑問への答えとしては両方である、ということになるだろう。オープンソースの定義によるオープンソースは、OSIが考える自由を実現するソフトウェアのライセンスおよびそのライセンスに基づいて配布されるソフトウェアのことであり、定義に合致するライセンスおよびソフトウェアはオープンソースというラベルを使用できることになるのである。

0.3. オープンソースの正しい表記

厳密に「Open Source」あるいは「オープンソース」という用語の表記法を定めた文書は存在しない。しかし、OSIがサービスのマークとして使用しているという観点、オープンソースの定義を書いたBruce Perensの考え方等から、この用語に対してある程度正しいと考えられる表記というものが存在すると考えて良い。通常、OSIが定める定義に沿ったオープンソースである基準に適合するライセンスもしくはソフトウェアに関しては「Open Source」と表記されるので、これに従うことが望ましいだろう。OSIの「Open Source」から派生した様々な考え方もそれに準ずると考えても良いかもしれない。ということで、Opensource、OpenSourceあるいはOpen-Sourceといったようには通常は表記されないが、ただし形容詞的に使用する場合には稀に使用されることもある。なお、Open Source softwareやOpen Source licenseという用語はそれぞれソフトウェアとライセンスを区分するためのサブセットということになる。

日本においては、一般的な外来語のカタカナ表記の慣行に従えば、OpenとSourceという二語の単語による複合語の記述はオープン・ソース、オープン　ソース、オープン-ソースといった表記が考えられるが、Open Source Group Japan(OSG-JP)が「オープンソース」の商標を登録しているという事情やそもそも既に用語として成熟していると考えて良いだろうから、「オープンソース」という表記が望ましいだろう。

1. 第一条：再頒布の自由

第1条以降の10箇条がオープンソースの定義の本体であるが、このオープンソースの定義にはそれぞれの条文毎に注釈が付いた注釈付き版というものが存在する。この注釈は元々のDFSGには存在せず、また正式なオープンソースの定義の一部でもないとされている。定義を書いたBruce Perensが補足的に解説を付け足したものだと思われるが、策定当時の技術的背景も垣間見えるので、その注釈部分も合わせて解説を進めていくこととする。

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

理由: ライセンスが自由な再頒布を要求するよう強制することにより、数多くの長期的利益をちょっとした短期的な販売収益を得るために投げ捨ててしまうというような誘惑を除くことができます。このような縛りをかけないと、協力者たちは変節せよという強い圧力にさらされてしまうでしょう。
https://opensource.jp/osd/osd19/#1

1.1. 第一センテンス

この第1条は「再頒布の自由」を定めている。そして、第一センテンスでは、オープンソースであるライセンスが、他の様々なソフトウェアと一緒になった集合体となったとしても有償か無償かを問わずライセンサー側が頒布という利用行為に及ぶことを制限してはならないことを示している。単に自由に頒布と書けば良さそうなところをわざわざソフトウェアの集合体と言えるdistributionという用語を使用し、複数のソフトウェアが同居する状態になったとしても自由な頒布行為を制限してはならないと書いているのである。これは単一のソフトウェアであれば制限可能という意味ではなく、様々な出自のソフトウェアと同梱されたとしてもそのソフトウェア自身の頒布は制限されないとう点を強調していると考えられる。

わざわざこの点だけを敢えて強調して再頒布の自由を唱えているのは、この定義の出自がDebianという主にLinuxディストリビューションを開発しているプロジェクトにあるからだろう。Linuxディストリビューションはまさしく様々なソフトウェアの集合体であり、Debianプロジェクトが考える自由を推進するためにはそのソフトウェアの集合体が有償であろうが無償であろうが自由に頒布されなければならない。それを具現化した条項がこのDFSGの第一条であり、それがそのままオープンソースの定義の第一条に流用されたのである。

このような経緯を踏まえると、決して集合体とは限らない様々な状態にあるオープンソースのライセンスに対する条件としてはこの第一センテンスは条件を細かく書き過ぎのようにも思えてくるが、オープンソースであるソフトウェアは原始の権利者の下から頒布されるだけで終わりではなく、その後に様々な媒体、メディアを経由して繰り返し頒布が為されていくことになる。そのような繰り返しの中でこの第一センテンスで書かれるような状態に置かれることがあると考えられるが、そうであっても頒布の自由が有効でなければならない。だから、この一条は「再頒布の自由」なのであり、その繰り返しのサイクルを強調する意味としてこの条文は効いているように考えられる。

1.2. 第二センテンス

第二センテンスは、販売のような有償での頒布行為に対し、報酬を得てはならないことを示している。これを有償であっても頒布は制限されないという第一センテンスと矛盾すると受け取る者がいるかもしれない。しかし、このセンテンスの主語は「ライセンスは」であり、つまりここで報酬を受け取ると想定されるのは元々の権利者であるライセンサー側である。第一センテンスで自由な頒布の許諾を受ける者にはこのセンテンスは何の影響も与えない。

Bruce Perensによる注釈はおそらくこのセンテンスに向けて主に書かれていると考えられる。策定当時の一般的な感覚からすると頒布に対して元々の権利者が何らかのフィーを取ろうとする感覚がまだ根強かったという感覚はあるが、そのような空気を払拭するための念押しをしておきたかったのかもしれない。

1.3. 第一条の解釈、機能

第一条で定めていることは、その表題通り「再頒布の自由」である。自由であるということは当然ながら有償であるか無償であるかという点は問われない。許諾を受けた者は物理メディアでの販売や貸与、ネットワークを通じた送信等の手法を問わず、ソースコードやバイナリといった形式も問わずに自由に頒布できる。そして、その頒布を行うライセンシー側は権利者に対してロイヤリティ等のフィーを支払う必要もなく、これらのライセンシー側が得た許諾は基本的に永続的に継続する。

著作権的な感覚で言えば、ライセンシー側は複製権と頒布権(公衆送信権)の永続的な許諾を得ることになると考えられ、これによってソフトウェアの私有化、独占化を防いでいるとも考えられる。なお、ここで複製権にも及ぶのはソフトウェアに関してはまず対象となるソフトウェアの複製(再製)が暗黙的に頒布の事実上の前提となるからである。

1.4. コピーレフトとパーミッシブ

オープンソースであるライセンスは二つの種類に大別することができる。GNU GPL(GNU General Public License)等のいわゆるコピーレフト・ライセンス(Copyleft License)とMITライセンス等のパーミッシブ・ライセンス(Permissive License)である。OSIによる定義としてはパーミッシブ・ライセンスとは「コピーレフトではないライセンス」であり、従ってオープンソースのライセンスはこの二種のみで区分できることになる。この二つに大別されたライセンスは各々第一条への適合は下記のように考えることができる。

コピーレフトのコンテキスト：

コピーレフトの場合、ライセンシーである利用者側には二次的著作物の作成を含むソフトウェアの改変が許可されるが、特に変更されたバージョンの頒布に対してもオリジナルのライセンスに基づいていなければならない。これによって、二次的著作物がオープンソースのままであることが保証される。OSD第一条では再頒布が許可されなければならないことのみが規定されており、そのための条件は指定されていない。よって、第一条とは矛盾していない。

パーミッシブのコンテキスト：

一方、パーミッシブ・ライセンスの場合、ライセンシー側は作成した二次的著作物の頒布に際して、独自のライセンスを付与することができる。これは二次的著作物がオープンソースとはならない可能性があることを意味するが、オリジナルのソフトウェアと同じライセンスで頒布することは許可されている。よって、第一条とは矛盾していない。

OSD第一条は自由な再頒布を要求するが、その条件は指定されていない。コピーレフトは派生のソフトウェアがオープンソースの状態を維持することを保証するのに対し、パーミッシブは派生作品のライセンス選択に関してより自由度を提供することになる。このようにアプローチは異なるが、双方共に第一条の要件を満たすことになる。

2. 第二条：ソースコード

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

理由: 私たちは、意図的に分かりにくくされていないソースコードが入手できることを要求します。プログラムを改変することなしにはプログラムを発展させることはできないからです。私たちの目的はソフトウェアの発展をより容易なものにすることですから、変更が簡単に行えることを必要条件に加えています。
https://opensource.jp/osd/osd19/#2

Introductionパラグラフの冒頭にて「単にソースコードが入手できるということだけを意味するのではありません」と書かれており、少なくともソースコードの入手性が条件の一つであることを暗に示していたが、この第二条にてそのままソースコードの入手性がオープンソースの条件であることが要求されている。それだけでなく、ソースコードの入手に対して幾つか条件が付いていることが第二条の特徴であり、十箇条の中で最も長いパラグラフとなっている。

2.1. 第一センテンス

第一センテンスは二つの文を接続しており、前半ではソースコードが含まれてなければならないこと、後半ではソースコード形式での頒布が許可されなければならないことを要求している。ソースコードが含まれているのであれば第一条の再頒布の自由により後半部は自明となるのではあるが、ここで改めてソースコード形式でソフトウェアが入手できることを条件として示しているのである。第一条としては配置されなかったもののやはり重要な概念であるのでこの位置に置かれたのだろう。

なお、ソフトウェアにソースコードを含んでなければならないとしているのに、ソースコードの頒布が「許可」とされており、これはソフトウェアの頒布行為時においてソースコードを必ずしも使用者に入手させる必要がないことを示している。これはソフトウェアがバイナリの実行形式で頒布される場合を意図しており、このような頒布形式の場合はどこかでソースコードが入手できるように手筈を整えておけば良いということになる。

2.2. 第二〜第五センテンス

第二から第五までのセンテンスは、第一センテンスでのソースコードの入手性に対してさらに条件を付け足している。

第二、第三センテンス：

第一センテンスではソフトウェアにソースコードが含まれなければならないとしてことに対し、第二センテンスはその例外を提示している。特段の事情があれば、頒布されるソフトウェアにソースコードを含ませる必要がなく、複製コストとして妥当な手数料を課すことも認められる何らかの別のソースコード入手手段があれば良いということである。第三センテンスではその入手手段を無料のダウンロード、つまりネットワーク上での頒布が望ましいことを示しているものの、これはあくまで推奨であり他の手段でも構わないということである。

現実的には多くのソフトウェアはネットワーク上でソースコードが頒布されているわけだが、この第二センテンスは特にGNU GPLを適用したソフトウェアが物理的製品に組み込まれる場合を想定している。GPLでは物理的製品への組み込みという形式の頒布に際して、最低三年間は書面による申し出で物理的媒体に固定した対応ソースコードを伝達するという条件が課されているが、このようなライセンス条件も明示的にオープンソースとして認めているのである。この第二センテンス以降の文言はDFSGには存在せず、オープンソースの定義から出現するものであるが、おそらく策定当時はまだLinuxは組み込み市場において支配的ではなく、条件を曖昧にすることで組み込み市場での採用に水を差すようなことを避けたかったのかもしれない。ただし、第一センテンスだけでもこの第二センテンスの内容は認められると考えて良く、基本的には例示しているに過ぎないと考えられる。

第四、第五センテンス：

第四、第五センテンスは、提供されるソースコードの形式について条件を付けている。ソースコードが「変更しやすい形態」でなければならず、「分かりにくく」することは許可されないということである。一言で言えば難読化をしてはいけないということであり、人間が書いたソースコードを完全な形で提供することを求めているわけである。

Bruce Perensによる注釈でも書かれているように「プログラムを改変することなしにはプログラムを発展させることはできない」ので、分かりやすく改変が容易な形式で頒布されることを求められている。これはソフトウェアの頒布に際しての条件ということではあるのだが、その後の改変(翻案)をより実行しやすくするためとも言え、すなわちここで暗黙的に改変を認めることが念頭に置かれており、そのための技術的に必要な要件を先に示しているとも考えられる。

ともかく、この第二条全体では、ソースコードの入手性だけでなく、提供されるソースコードが改変(翻案)に適した形式で利用できるようにすることの重要性を強調している。また、当然ながらソースコードの完全な入手性は様々な環境下における再製を容易にするということでもあり、複製権の許諾とそこに付随するソフトウェアを研究する自由も内包していると考えることもできる。第二条は頒布に際しての条件でありながらも自由な複製と改変・改良行為までを含めたオープンソースのエコシステムのサイクル全体に対して規範を示していると言えるだろう。

3. 第三条：派生ソフトウェア

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

理由: 単にソースを読むことができるだけでは、独立したピアレビューや急速な発展的淘汰を維持するのに十分ではありません。急速な進化を実際に起こすためには、人々がそのソフトウェアでさまざまに実験し、変更点を再頒布することができる必要があります。
https://opensource.jp/osd/osd19/#3

第三条は一つのセンテンスから成る短い条項であるが、オープンソースにとって最も重要な概念を示している。ここでは単にソフトウェアの改変を認めるだけでなく、それによっての派生ソフトウェアの作成とそのライセンスに関する条件について触れているのである。

センテンス前半部：
条文の前半では、ソフトウェアの変更(改変・改良)を認め、その改変部分がオリジナルのソフトウェア部分とが合わさった派生ソフトウェアの作成を可能とするライセンス条件を持つことをオープンソースと定義する条件としている。これは著作権のコンテキストでは、翻案権の許諾を行うと共に、翻案された著作物を二次的著作物もしくは結合著作物として公開することまでを要件としていると考えられる。

センテンス後半部：
後半部では、派生ソフトウェアがオリジナルのソフトウェアと同一のライセンスで頒布されることを「許可」しなければならないと定めている。このロジックは1.4節で解説したコピーレフトとパーミッシブの件と同様の解釈であり、コピーレフトであれば変更されたバージョンの頒布に対してもオリジナルのライセンスに基づいていなければならないのでこの後半部の「許可」の条件をパスし、パーミッシブであれば単に変更物も含めてオリジナルのライセンスに基づくことを「許可」されているのでパスすることになる。ここでは単に二次的著作物が同じライセンスで頒布されることが許可されていることが重要である。

この第三条全体でライセンスに求めていることは、ソフトウェアを改変(翻案)するだけでなく、その改変によって派生ソフトウェアである二次的著作物を作成し、その二次的著作物を頒布するまでのサイクル全体に及ぶ許諾を行うことであり、それをオープンソースであるための条件としている。通常、ソフトウェアにおける著作権は複製、翻案、頒布に対する独占権が発生するものであるが、第三条はこれらの権利のほとんどをライセンシー側へ与えることになる。この許諾によって、ソフトウェアの改変、改変物の原著作物への結合、二次的著作物の再頒布の自由、そしてライセンスを確認する必要がない無駄のないサイクルが生まれ、オープンソースのエコシステムが形成される一助となるのである。

なお、ソフトウェアの改変によって二次的著作物が創作されるということは、原著作物の著作権と改変箇所の著作権がそこへ併存するということである。この派生物の作成のサイクルを繰り返すことが多くのオープンソースの開発プロジェクトで行われていることであるが、このサイクルによって一つのソフトウェアの著作物において非常に多くの著作権が併存することになる。この第三条によって特にライセンサーの許諾がなくとも自由に派生サイクルを永久に回し続けることが可能になるとも考えられるだろう。

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

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

理由: 盛んに改良することを奨励するのは良いことですが、ユーザには彼らが使っているソフトウェアについて誰が責任を持っているのか知る権利があります。反対に、ソフトウェアの作者と管理者にも彼らの名声を保護し、何をサポートすることが要求されているのか知る権利があります。
それゆえ、オープンソースなライセンスはそのソースが容易に入手可能であることを保証しなければならないのですが、一方でそれがいっさい変更されていない本来の基本ソースとパッチという形で頒布することを義務付けても構わないということにします。こうすれば、「非公式」な変更点は利用可能でありつつも、元のソースとは簡単に見分けがつくわけです。
https://opensource.jp/osd/osd19/#4

OSDの元となったDFSGは、Linuxディストリビューションを頒布するプロジェクトの中で策定されたという経緯があるだけに、この第四条は実にディストリビューションのパッケージ開発での都合が思い浮かぶ条文である。

第一センテンスは、バイナリのビルド等においてオリジナルのソースコードと改変箇所に該当するパッチファイルをセットとして頒布する場合には、それらの結合物である派生ソースコードの頒布を制限できるとしており、第二センテンスではその結合物である派生ソースコードの頒布の際にはオリジナルのソースコードとは異なる名前とバージョンを義務付けることは問題ないとしている。

4.1. 技術的観点

テクニカルな話をすれば、この第四条でのパッチファイルとは二つのファイル間の差異が記述されたファイルのことであり、オリジナルのソフトウェアに改変を施した際には改変されたソフトウェアとの差分を取得することでパッチファイルとなる。つまり、オリジナルのソフトウェアにパッチファイルという差分を追加または結合することで改変ソフトウェアとすることができる。これによってオリジナルのソースコードをそのまま残して整合性を維持しながら、その差分の適用によって改変ソフトウェアへの変更を自在に行うことが可能になる。このような仕組みはオリジナルと派生物の区別を行うために有用であり、ソフトウェアのメンテナンスやトラブルシューティングにおいて不可欠の考え方である。

第三条までの条文は基本的に対象ソフトウェアに発生する複製、翻案、頒布に対応する支分権に対して自由な利用の許諾を認めることを要件として挙げているわけであるが、この第四条はそのような法的権利に対する条件とは全く趣が異なり、基本的にはソースコードレベルからの改変の自由とオリジナルの作者の権利や開発プロジェクトの運営におけるバランスを取るためのテクニカルな手法について言及されていると言える。そのため、オープンソースであるための条件というよりも、開発プロジェクトを進めるにおいてのマナーや規範的な性格の方が強い。

4.2. 法的観点

第四条は規範的な性格が強いという性質ながらも、法的な要素を全く含まないということではない。基本的には著作者人格権にこの条項は触れていると考えられるだろう。Bruce Perensによる注釈にも触れられているように、オリジナルの作者には著作物に対して氏名を表示して利用者に知らせる権利があるし、作者の名声を保護するために意に沿わない改変を拒否する権利や名誉声望を害する方法での利用を禁止する権利もある。日本法に照らし合わせれば、氏名表示権、同一性保持権、名誉声望保持権といった権利である。

この第四条は、オリジナルの作者の著作物の完全性および帰属を維持する権利と、その対象ソフトウェアを改変および頒布するライセンシー側が許諾によって獲得した権利との間で適切なバランスを取るように作用していると言えるだろう。

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

5. 個人やグループに対する差別の禁止
ライセンスは特定の個人やグループを差別してはなりません。

理由: 進化の過程から最大の恩恵を引き出すためには、可能な限り多種多様な人々やグループに、平等にオープンソースに貢献する資格が与えられている必要があります。そこで、オープンソースなライセンスによって誰かを進化の過程から締め出すことは禁止されています。
アメリカ合衆国を含むいくつかの国では、ある種のソフトウェアに輸出制限を課しています。OSD準拠のライセンスは、適用される可能性がある制限についてライセンス受諾者に警告し、また彼らには法に従う義務があることを示唆しても構いません。しかし、ライセンス自身にそのような制限を取り込んではなりません。
https://opensource.jp/osd/osd19/#5

第三条までの著作権上での許諾に対する条件に対し、第五条からはそれらの条件への補足的な要件が続く。そして、この第五条はライセンスによって「個人やグループに対する差別」を行うことを禁止ということで、極めて簡潔であり、かつ倫理的な条文となっている。条文の意味としては、特定の個人やグループが対象ソフトウェアの自由な利用の権利に差異があってはならないということである。つまり、個人の特性や所属に関係なく、対象ソフトウェアとそのソースコードが誰でもアクセスでき、利用できる必要があることを意味している。

このような公平性は当然のことであるように思いがちであるが、許諾を行う当事者になってみると自分が開発したソフトウェアを自分が気に入らない者に対して利用させたくないという心理は得てして生じるものである。単に嫌いというのもあるだろうし、ビジネス的な競合あるいは自分の信条や倫理に反する者がソフトウェアの利用という利益を享受することに心から喜べる者は少ないだろう。しかし、この第五条により、全てのライセンシーにおいて権利が公正かつ公平であることが保証され、ソフトウェア利用に際しての普遍性を維持し、それによって協力的で包括的なコミュニティとエコシステムの発展を促進することにも繋がるのである。

5.1. 注釈における輸出規制

Bruce Perensの注釈において、第一パラグラフは特に変わったことは書かれていないが、第二パラグラフでは唐突に輸出制限について触れている。これは特に米国において当時はまだ規制が強かった暗号技術の輸出が念頭に置かれていると考えられている。第二次世界大戦以降から1992年までは国家安全保障上の理由により米国及びNATOを中心とした強い暗号輸出規制が敷かれていたが、これらの規制は2000年に商用およびオープンソースの暗号技術輸出に関する大幅な規制緩和がなされることで解消された。つまり、定義が書かれた1998年当時にはまだ規制がまだ強かったこともあり、敢えて注釈として記述されたのだろう。

現在では定義策定の当時のような実務において強過ぎる輸出規制があるわけではないし、特にオープンソースの場合は米国の輸出管理規制において「公開されているオープンソースは規制対象ではない」とされており、多くの国においても特段の配慮がなされている。ただし、それでも幾許かの制限は残存しており、また特に米国とその同盟国から見てのテロ支援国家に対する技術輸出には大きな制限が存在する。

ライセンスによって許諾を出す存在は個人または法人であるが、これらの「人」はあくまで国家に属した存在である。国家によってある種の国もしくは人々への輸出が法によって規制されることで頒布が不可能になるのであれば、ライセンスでその規制と同様の制限をしてはならないが、法域の法に従うのは仕方がないということをこの注釈で述べられているわけである。ただし、この部分はあくまで注釈であり、オープンソースという概念を超えた次元の問題であるので、実務上は特に気にする必要はないだろう。

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

6. 利用する分野(fields of endeavor)に対する差別の禁止
ライセンスはある特定の分野でプログラムを使うことを制限してはなりません。例えば、プログラムの企業での使用や、遺伝子研究の分野での使用を制限してはなりません。

理由: この条項の主な意図は、ライセンスによってオープンソースが商業的に使われることを妨げるような策略を禁止することです。私たちは、営利的なユーザも私たちのコミュニティに加入してくれることを望んでおり、彼らがそこから排除されているような気分になっては欲しくないのです。
https://opensource.jp/osd/osd19/#6

第六条は第五条とよく似た一見倫理的な条文である。一言で説明すれば、「利用する分野」を差別するライセンスを定めることを禁止しているということになる。第一センテンスではその文字通りのことが書かれており、第二センテンスではその禁止例として企業(営利活動)においての使用や遺伝子研究分野での使用を挙げている。第五条はあくまで「人」の差別であるが、この第六条ではソフトウェアの「用途」において差別してはならないということを定めているのである。

ライセンスによる用途の制限は歴史的に見ると二つの系統があり、一つは単に自分が開発したソフトウェアを他者の営利目的で使用させたくないといった人の損得的な感情から発生するものであり、もう一方は作者自身の倫理観や信条から発生するものである。条文では短く双方に対応する例が挙げられているわけだが、前者は歴史的にずっと根強く存在し、後者は時には世界的な情勢の変化に合わせて新しい考え方が次々と発生してくる。

Bruce Perensの注釈では基本的に営利活動での使用を禁止してはならない旨のことだけが書かれている。これは定義の策定当時において、そもそもオープンソースという新しい用語をコミュニティが歓迎した理由の一つに様々な企業とビジネスユーザーがコミュニティに加わることを欲したということがあり、そのような状況下で書かれたからこそ営利を排除してはならないと念を押すことになったのだろう。これに対して後者の個人の倫理観に基づく用途制限については、策定当時では軍事的研究への利用を禁止する等の割と限定的なライセンスの試みが多かったように思うが、近年は社会が複雑化するに従い、児童虐待、民族弾圧、性的指向や自認、プライバシー等といった広範な人権問題が絡められるケースも出てきているようである。

しかしながら、これらの個人の感情、倫理観、信条等によってソフトウェアの用途を制限することは、公平性や自由の原則や幅広い適用性といったオープンソースのメリットを棄損させ、第五条でも触れた協力的で包括的なコミュニティとエコシステムの発展を阻害することにも繋がるだろう。そもそも人間は経済的活動からの享受がなければ生きていけないし、個人の思想や倫理というものは千差万別であり他人から見れば全く異質な考え方の方が倫理的という場合もあるだろう。どのような場合であっても、第五条での「人」の差別やこの第六条での「用途」の差別がないことは、このような考え方の違いを越えてコラボレーションを行う手段を提供し、イノベーションを起こす素となるのである。

6.1. 使用と利用

この第六条の日本語訳は「利用する分野」に対する差別の禁止であるが、原文では「Fields of Endeavor」に対する差別の禁止となっている。通常、Endeavorという単語は「努力」だとか「試み」といった意味で訳されるので直訳すれば努力分野ということになるのだが、特に特許権の世界では「Fields of Endeavor」という表現で、発明者が発明を実現もしくは創作しようとした適用範囲ぐらいの意味となる。このやや古めかしい表現をBruce Perensが条文のタイトルとして選んだ理由は分からないが、条文と注釈からは明らかに対象ソフトウェアが使われ、利用される分野、用途のことを指していることは明らかであるし、ライセンスとは著作権の利用許諾であるわけなので「利用する分野」という八田真行の訳は適切であるように思う。

しかしながら、興味深いことに第六条の条文では「利用」といういかにも著作権由来の用語ではなく、「使う」もしくは「使用」という訳語を割り当てている。ここでは「Use」の訳語として「使用」を当てているのであるが、著作権的な感覚ではここは「利用」の方が適切であるように思えてくる。オープンソースの定義は著作権ライセンスのための定義でもあるわけであり、ソフトウェアの著作権では通常は権利者に独占権が発生しない「使用」の部分に触れてもしょうがないと考えられるからである。ただ、英語におけるUseは非常に幅広い意味で解釈できるものの、やはり一般的な「使用」を意味するだろうし、第六条で念頭に置かれている用途に制限のあるライセンスは得てして著作権における「利用行為」の範囲だけでなく、単なる「使用」のレベルから制限をライセンスとして加えているものが多い。「このソフトウェアを軍事目的には使用してはいけない」等といった条文は正にそれに該当するだろう。第六条で禁止したいことはこのような使用のレイヤーからも含めた用途の制限であるわけなので、条文の意図としては「使用」を含めて問題ないのであろう。

6.2. 特定のクラウド企業を排除するライセンス

2018年前後から特定の巨大企業もしくはその巨大企業が運営するクラウドサービスを排除する目的のライセンスが幾つか登場している。当然だが、それらのライセンスはこの第六条等に反しており、オープンソースと称することはできない。このような利用用途によって特定の企業を排除するような動きは近年になって始まったものではなく、オープンソースの熱狂期の後にMicrosoftが立ち上げたShared Sourceもそのタイプの運動の一つであるだろう。Shared Sourceはオープンソースの理念を薄めようとする運動であるとの批判が多かったが、その中の一部のライセンスはオープンソースの定義に合致しており、必ずしも敵対化とは言えない概念であったように考えられる。しかし、近年の特定企業を排除する動きは明確にオープンソースのコミュニティとそのエコシステムに敵対する動きであるだろう。

これらの巨大企業やクラウドサービスを排除しようとするライセンスを採用する企業は元々GNU AGPL(GNU Affero General Public License)を採用していた企業が多いという特徴があるが、コピーレフトの考え方である変更されたバージョンの頒布に対してもオリジナルのライセンスに基づいていなければならないというライセンスの伝搬性を利用し、対象ソフトウェアが生み出す市場に対して開発者である企業の影響力の保持を企図していたと考えられる。ここまでは正当なオープンソースを利用したビジネス形態であるが、単にソフトウェアを「使用」する企業に対して使用の禁止、あるいは他の第三者権利の著作物であるソフトウェアへも自身のライセンス伝搬を迫るようなライセンスはオープンソースではないし、そもそも全く倫理的ではない。

7. 第七条：ライセンスの分配(distribution)

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

理由: この条項は、ソフトウェアを機密保持契約への同意を要求するなどの間接的な手段によって囲い込むことの禁止を目的としています。
https://opensource.jp/osd/osd19/#7

第七条も簡潔な一つのセンテンスで書かれており、また内容としては第一条「再頒布の自由」のサブセットのような位置付けのようになっている。このセンテンスでは、対象ソフトウェアを頒布する際にライセンシー側へ付与される権利が全ての者へ等しくなければならないとし、さらにその際には追加ライセンスの締結等を必要としてもならないことを定めている。

Bruce Perensの注釈によればここでの追加ライセンスの例として機密保持契約が挙げられているが、これは対象ソフトウェアをオープンソースのライセンス付与した上で頒布しておいてから、頒布を受ける者との間の契約によってライセンスで許諾された権利を毀損させることは認められないということである。これはさすがに当たり前だろうと言いたくはなるが、ソフトウェアの世界においては契約で使用および利用を制限することがソフトウェア著作権の一般化よりも先に慣行化されており、定義の策定時においては契約で利用が縛られるリスクというものをまだ感じられる時代だったために敢えて独立して条件として書かれたのかもしれない。

この第七条は、ソフトウェアの頒布を受けた際に誰がいつどのような時に受け取った時でも同一のソフトウェアであれば同じ権利が永続的に付与されることを意味しており、許諾が剥奪されたり変更されたりすることから法的に保護されることになる。これにより、その対象ソフトウェアのサプライチェーン上における全ての関係者において同じ自由と権利が共有され、保持されることにもなる。このようにこの第七条は、オープンソースのライセンスにおいて一貫性、明確性、永続性を維持するために重要な役割を果たす。

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

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

理由: この条項は、ライセンスによるこれまたよくあるタイプの策略を禁止します。
https://opensource.jp/osd/osd19/#8

第八条は「特定製品でのみ有効なライセンスの禁止」である。これは時々、特定製品を対象とするようなライセンス条文の禁止と読み違えられることがあるが、第一センテンスで書かれているように特定製品に付属もしくは組み込まれたような形態でなければ権利付与がされないようなライセンスは認められないということである。第二センテンスでは、そのことを明確とするための例示として、特定製品に組み込まれたようなソフトウェアを取り出したとしても、元のソフトウェアに対して製品の使用者に与えられた権利と同等の権利が取り出したソフトウェアの頒布を受けた者へ与えられることを挙げている。これは第七条と同様に第一条の再頒布の自由のサブセット的な条文であると言える。

条文からは特定製品という何らかのハードウェア的な製品に組み込まれるソフトウェアを思い浮かべるが、特にそのような狭い状況に限ったものではなく、ディストリビューションにおけるパッケージ化やソフトウェアのバンドル、あるいは何らかの使用制限が課せられるような法的条件下等の幅広い頒布に関する形態によっても左右されず、どのような形態でも同一のライセンスの適用され、汎用性が維持されるることを意味している。

技術的な面で見れば、特定の製品や法的状況下に縛られないことになり、ソフトウェアを様々な状況で統合して利用できるモジュール性と再利用性が促進されるとも考えられるだろう。また、他のソフトウェアと一緒に自由に使用、改変、再頒布できることが保証されることにもなり、単一のベンダーや製品への依存を防ぐという意味合いもあるだろう。

さらに、法的に見れば、どのような状況下でも一貫性のあるライセンスが適用されるということであり、これは特にオープンソースの他ソフトウェアとの互換性に影響し、他ソフトウェアとの組み合わせ、あるいは結合するような状況でもライセンス以外の余計な制限が課されないことが保証されることになる。

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

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

理由: オープンソースなソフトウェアの頒布者には、彼ら自身のソフトウェアについては彼ら自身で選択する権利があります。

もちろんGPLはこの要件を満たしています。GPLが適用されたライブラリとリンクされたソフトウェアは、それが単一の著作物を形成する場合のみGPLを継承するのであって、単に一緒に頒布されるというだけならば他のソフトウェアには影響しません。
https://opensource.jp/osd/osd19/#9

第一センテンスそのままではあるが、この第九条は対象ソフトウェアと共に頒布される他のソフトウェアが存在した場合に対象ソフトウェアのライセンスが他のソフトウェアに何らかの制限を課してはならないことを示している。そして、第二センテンスでは、同じ媒体、例えば同じディストリビューションにおいて、特定のソフトウェアのライセンスが他のソフトウェアを全てオープンソースであるように要求してはならないという例示を行なっている。

この例示は、オープンソースの定義が元来はDFSGというDebianディストリビューションを頒布するプロジェクトのための定義であったことを色濃く反映していると考えられ、ようは様々なライセンスが付与されたソフトウェアの集合体であるLinuxディストリビューション等においては特定ソフトウェアのライセンスが他のソフトウェアに制限をかけるようなことがあっては非常に困るというわけである。例示のような全てオープンソースであれば問題ないじゃないかという考え方があるかもしれないが、少なくとも相手側に対して相互に制限を掛け合うような状況が発生した場合には行き詰まるだろう。このような法的矛盾を回避し、個々のソフトウェアの独立性を保証することで多様なライセンスの選択肢の整合性を維持し、堅牢なソフトウェアのエコシステムを作り出す基となるのである。

なお、ライセンスは著作権の許諾であるということを踏まえると、そもそも対象ソフトウェアとは異なる他のソフトウェアというものには対象ソフトウェアの著作権は及ばないわけであり、当然ながら何らかの契約関係がない限りはそもそも他のソフトウェアに対して何の権利も発生しない。このように著作権システムとしては至極当然のことが書かれているに過ぎないのであるが、第九条はプロプライエタリな業界での契約の世界との整合性も含めた上でこれを明示的にすることにより、ライセンスの互換性を気にせずにソフトウェアの集合物を作成でき、様々な利用の場面での適用性と実用性を強化していることになる。

9.1. 第九条へのGPLの適合性

ここでGNU GPLのようなコピーレフトのライセンスの存在を疑問に持つ方が出てくるかもしれない。改変されたソフトウェアの頒布に対してもオリジナルのライセンスに基づいていなければならないというライセンスの伝搬性をGPL的なライセンスは持っているわけであるが、改変側を他のソフトウェアとみなせば第九条に反すると感じる可能性はあるだろう。

この疑問を解消するためには二次的著作物の概念を理解することが必要になる。二次的著作物とは先に創作されたオリジナルの著作物から著作物性がある表現要素を取り込んだ創作的表現物のことであり、二次的という名が示すようにその新たな表現物は第二の別の著作物となる。ソフトウェアの著作物であれば、単に何かの機能を改変したソフトウェアや別のプロジェクトとしてフォーク(分岐)したソフトウェア等のケースが該当するし、オリジナルがライブラリのようなものであればそれらを取り込んで結合したソフトウェアも二次的著作物として該当する。

このような二次的著作物には新たな著作物として著作権が発生するし、二次側(改変側)で新たに追加されたソースコードの方が充分に大きい状況であれば二次的著作物の作者単独の権利として考えたくなるようなこともあるだろう。しかし、二次的著作物とはあくまでオリジナルの著作物を基にして成り立っており、よってその二次的著作物にはオリジナルの著作物に発生する著作権が併存することになる。コピーレフトとはこのような二次的著作物に残存するオリジナルの著作者の権利を用いた仕組みであり、二次的著作物であるソフトウェアを創作するにあたっての条件を示しているに過ぎない。これは自分のソフトウェア著作物の利用に際しての正当な条件を課しているということであり、「他のソフトウェア」を制限するということには該当しないのである。

GNU GPLファミリー等のコピーレフトのライセンスは自由を継続性を実現しているが、同時に別のライセンスを付与されたソフトウェアの独立性も尊重している。GPLにおけるライセンス伝搬性というものはあくまでオリジナルの著作物の権利が及ぶ範囲だけに留まるものであり、派生でも結合でもない単に同梱されているような他のソフトウェアに感染したり制限を課したりすることはなく、第九条で定義されている原則との互換性を維持している。

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

10.1. 第十条へ至るまでの経緯

最後の第十条は少々複雑な経緯で策定されているので最初にその経緯を説明する。

オープンソースの定義は元々DFSGであったとは既に解説済みであるが、DFSGの第十条としてはこの「技術中立的でなければならない」といったような条文は存在しない。DFSGの第十条はDebianとしてフリーソフトウェアと認めるライセンスの例示がなされているだけである。なお、そこでは「GPL, BSD, and Artistic licenses」がフリーであると書かれている。オープンソースの定義の第十条は当初DFSGの第十条がそのまま流用されたのだが、オープンソースと呼ぶべきライセンスは当然他にも存在するし、定義が世間において定着するに従って第十条に追加すべきライセンスというものが次々と出てきた。その度に定義を改定というのは合理的ではないので、最初の第十条は削除され、オープンソース・ライセンスの審査プロセスとリストは定義とは別に存在するようになったわけである。

その後、第十条にはライセンス審査プロセスやオープンソースを示すマークとして知られる緑色の鍵穴的なOSI認定マークの説明が書かれていたのだが、2004年の定義のv1.9にて現在の第十条に置き換えられた。この現在の第十条は以前までの版と比較してオープンソースとされる条件や範囲が変わったということではなく、2004年当時までに起きたネットワーク環境の変容に対してオープンソースとしての理念を明確にするために追加されたと考えられる。

10.2. 条文解説

10. ライセンスは技術中立的でなければならない
ライセンス中に、特定の技術やインターフェースの様式に強く依存するような規定があってはなりません。

理由: この規定で特に念頭に置いているのは、ライセンサーとライセンシーの間で契約を成立させるために明示的な同意の意思表示を必要とするようなライセンスです。いわゆる「クリックラップ(click-wrap)」を要求する規定は、ソフトウェア頒布において重要な手法であるFTPダウンロードや CD-ROMアンソロジー、ウェブのミラーリングなどと衝突する可能性がありますので、このような規定もコードの再利用を妨げてしまいます。よって、本定義に準拠するライセンスは、(a) ソフトウェアの再頒布が、ダウンロード時のクリックラップをサポートしないようなウェブ以外の経路で起こりうるという可能性 (b) ライセンスで保護されるコード (あるいは保護されるコードの再利用された部分) はポップアップダイアログをサポートできない非GUIの環境でも実行されうるという可能性、を認めなければなりません。
https://opensource.jp/osd/osd19/#10

第十条は条文としては非常にシンプルである。ライセンスに「特定の技術やインターフェースの様式に強く依存するような規定」があってはならず、すなわち技術に対して中立的でなければならないということである。ただ、この条文だけではライセンスが「技術に依存」だとか「中立的でなければ」といった状況とは一体何のことであるのか分かりにくいだろう。

この疑問の回答は注釈でされており、この第十条の策定は主にクリックラップ契約へ対応することが念頭に置かれている。元々のクリックラップとは何らかの物理媒体に固定化した製品を透明フィルムによって包装し、使用者がそのフィルムを破いた時点で使用許諾契約を成立させようとする仕組みのことであったが、この2004年当時までには様々なサービスのネットワーク化が進み、ネットワークもしくはコンピューター上のサービスを享受する際に使用許諾契約、プライバシーポリシー等への同意をボタンやチェックボックスのクリック一つで済ませることの意味へと変容していた。特にプロプライエタリのソフトウェアの領域ではそれ以前から同様であり、ソフトウェアのダウンロード、インストール、使用開始前等でボタン一つで使用許諾契約へ合意させることが一般的であり、その慣行がオープンソースの世界でも行われるようになっていた。

第十条の注釈部分では、オープンソースのライセンスを付与したソフトウェアにおいてこのようなクリックラップでライセンスに同意させる行為を強制させることは、様々な再頒布の手法と衝突すると言っているわけである。例えば、サイトからのダウンロード時にボタンでライセンスに同意させたとして、その頒布を受けた者はどうやって再頒布を行えばいいのだろうか？このような自由との矛盾が生じるのである。よって、その解決方法としてソフトウェアがクリップラップが技術的に不可能な経路でも頒布がされる可能性や非GUI環境でも対象ソフトウェアが実行される可能性を認めなければならないと、注釈部分でありながらも事実上の条件を定めている。分かりにくい表現であるが、これは要するにクリップラップでライセンスに同意させても構わないが、その同意がなくてもライセンスが有効な許諾であることを認めなさいという意味で考えると良いだろう。

なお、クリックラップはあくまで注釈部分で書かれていることであり、第十条の条文はあくまで「特定の技術やインターフェースの様式に強く依存するような規定」を否定しているのみである。これはクリックラップの問題を契機として、その後に出てくると予測された新しい技術的な問題にもまとめて対応しようとした結果であり、オープンソース・ライセンスの完全性と原則を明確にするために定められたのである。つまり、それらの新しい技術によってライセンスに制限がかかることを防ぎ、ソフトウェアを自由に使用したり、他の技術コンポーネントと組み合わせることが保証され、様々な技術的状況における適用性を強化しているのである。

10.3. 許諾と契約

本稿の0章において「頒布条件」という用語の解説を行なった際、既に「オープンソースの文脈においてのライセンスは著作権を主体とする知的財産権の利用許諾」と書いているが、この第十条の注釈において事実上オープンソースのライセンスが契約ではなく許諾であることを暗に示していると考えることもできる。

クリックラップに関する注釈では、少なくともクリックによる同意という契約行為がなくとも再頒布や実行のサイクルが発生する状況を認めるように定めていると言え、つまり単なる権利者側からの一方的な著作権の利用許諾であることをオープンソースであることの要件にしているとみなすことも可能だろう。ただし、この部分はあくまで注釈であり定義本体の条文ではなく、またIntroductionで出てくる「頒布条件」という用語は著作権の利用許諾よりも広い意味であることには違いないので、本定義上の解釈でオープンソースに契約を含まないとは言い切れるものではない

しかしながら、その他の条文を見ても分かるように、著作権が発生する部分に対する利用とそれに付随する広範な技術要件をクリアするためには当事者間の同意を必要とする契約と捉えることには無理があると言え、オープンソースのライセンスは許諾であると考えて実務上は問題ないだろう。

なお、特にGNU GPLにおいては契約であるかどうかが議論の対象となることがあるが、FSFはGNU GPLを含む自由なソフトウェアは著作権の利用許諾と考えているし、OSIもそれを尊重していることは確かである。米国や中国における幾つかの訴訟でGNU GPLの契約性を認めるような判示も存在するのであるが、契約性の問題はライセンス違反時における利用許諾(もしくは契約)の終了時において違反した者が法的に負うべき債務が異なるということに主に集約され、これはGPL等の個別のライセンスもしくは法域の違いから発生する問題と考えて良いだろう。

11. まとめ

オープンソースの定義は、ライセンスおよびソフトウェアがオープンソースであるための条件を著作権ならびに技術を含めた広範な各種の原則から構成されている。これまでの解説をまとめると下記のようになる。

第一条から第三条 – 著作権における各支分権の利用許諾に焦点：

第一条 (自由な再頒布)：無制限で自由な再頒布を規定
第二条 (ソースコード入手性)：ソースコードへ容易にアクセスできることを規定
第三条 (改変と派生著作物作成)：自由な改変と派生著作物の作成の保証と同一ライセンスでの頒布の許可を規定

第四条以降 – 技術面を含むより広範な原則を明確化：

第四条 (ソースコードの完全性)：元のソースコードの完全性を維持する作者の権利と改変の自由とのバランスを取る
第五条から第十条：個人やグループ、あるいは用途等のおいて差別がなく、技術的に中立で何ら制限もない広範な原則を明確化

オープンソースの定義における各条項は、オープンソースであるソフトウェアがコミュニティにとって自由にアクセス可能で利用可能な状態を維持することを保証するとともに、オリジナルの開発者の権利を尊重し、日々進化する技術環境に適応することも求めている。特に第三条までの条文は、著作権における複製、翻案、公衆送信、頒布に該当する各支分権に対する許諾に対処するものであり、第四条以降の条文はそれらの権利の許諾によって与えられた自由の内容を捕捉し、オープンソースの理念を維持するためのより広範な原理原則を明確化していると言える。

このようにオープンソースの定義は、オープンソースのコミュニティとエコシステムを支える最も重要な基盤であり、ソフトウェアの使用、改変、再頒布の自由を保証することでソフトウェア開発における透明性を協働開発の促進、ならびに継続的なイノベーションと改善サイクルを促進し、開発者と利用者の権利のバランスと取りつつ、ソフトウェア開発において進化する技術と新たな課題に適応を続けている。クラウドやAI等のテクノロジーに関連する問題への対処が将来的に加えられる可能性はあるが、オープンソースの定義はソフトウェア業界の将来を形成する基盤要素として、自由で協調的かつ革新的なソフトウェア開発の環境を維持する上で重要な役割を果たし続けるだろう。

参考：

Debian社会契約：https://www.debian.org/social_contract
自由ソフトウェアとは？：https://www.gnu.org/philosophy/free-sw.html
The Open Source Definition (Annotated)：https://opensource.org/definition-annotated/
オープンソースの定義日本語訳 (注釈版)：https://opensource.jp/osd/osd19/

許諾：

付録：

本編におけるオープンソースの定義の逐条解説を補完する内容の文書を以下に付録として収録した。

付録1：定義から見るオープンソースに至るまでの歴史
付録2：オープンソースと自由ソフトウェアの違い
付録3：オープンソースは何故パブリックドメインを含まないのか？
付録4：無保証と免責の条項
付録5：「頒布」という訳語を使用するのは何故か？
付録6：倫理を振りかざすライセンスが好ましくないのは何故か？

付録1：定義から見るオープンソースに至るまでの歴史

オープンソースの定義はDebianフリーソフトウェア・ガイドライン(DFSG)を流用したことは周知の事実であるが、何故Debianプロジェクトは一般的にはFree Softwareという用語の祖とも管理者ともみなされるFree Software Foundation(FSF)とは別に自由なソフトウェアの定義を定めたのだろうか？この疑問を解き明かすため、用語の定義から見た自由なソフトウェアの歴史についてここで述べる。

FSFの自由ソフトウェア

いわゆる自由ソフトウェア(Free Software)運動の開始は、1983年9月にRichard StallmanがUSENETニュースグループに「GNU(Gnu’s Not Unix)と呼ばれる完全なUNIX互換システム」の開発開始を宣言するメッセージを投稿したことが起源とされることが多い。ただし、この時のRichard StallmanによるメッセージにはFree Softwareという用語は出てくるものの、その意味の定義は特になく単に文脈に沿って自由な状態にあるソフトウェアを漠然と意味していたように考えられる。当時は米国においてソフトウェアに著作権が認められることが確定して間もない頃であり、機密保持契約やソフトウェア使用許諾契約に署名することへの怒りのほうが目立つ文章であった。この時にはFree Softwareが指す領域を明確に指し示すことについては特に考えが及んでいなかったのだろう。

その後の1985年にGNU Manifesto(GNU宣言)が発表された。これはGNUプロジェクトの目標を説明した文書であり、自由ソフトウェア運動の哲学的な基盤と考えられているが、自由ソフトウェアというよりもGNUが目指す世界の哲学が述べられた文章であり、自由ソフトウェアが何であるかについてはここでもはっきりとはされていなかった。

自由ソフトウェアが何であるか？という問いへの回答になりえるような文章として最古と認識されているものは、GNUプロジェクトの会報であるGNU’s Bulletin 1986年2月号の中での下記の記述である。

The Free Software Foundation is dedicated to eliminating restrictions on copying, redistribution, understanding and modification of software.
(Free Software Foundationは、ソフトウェアの複製、再頒布、研究、改変に関する制限を撤廃することに専心しています。)

The word “free” in our name does not refer to price; it refers to freedom. First, the freedom to copy a program and redistribute it to your neighbors, so that they can use it as well as you. Second, the freedom to change a program, so that you can control it instead of it controlling you; for this, the source code must be made available to you.
(私たちの名前にある “Free”という言葉は値段のことではなく、自由のことです。第一に、プログラムを複製し、あなたの隣人に再頒布する自由。第二に、プログラムを改変する自由です。そうすれば、プログラムがあなたを制御する代わりに、あなたがプログラムを制御することができます。)

GNU’s Bulletinの8ページ目からのFSFという団体を説明する文章の冒頭にてこの記述が出てくるのだが、この時点でソフトウェアに関係する著作権上の権利における自由を意識していることが分かる。そして、その自由である条件として第一として「複製と再頒布の自由」、第二として「改変する自由」を挙げていることも分かる。ただし、これがFree Softwareであるとははっきりと書かれておらず、そもそもFSFという団体の目的を説明する長い文章の中の一節に過ぎないことから、これをFree Softwareの定義として強く認識している者はさほどいなかったのではないかと考えられる。むしろ、GNU Manifestoによるソフトウェアがあるべき哲学や倫理観のほうが強く意識されていただろう。

当時のGNU’s Bulletinは半年に一度発行される会報だったのだが、最初の号からほどなく同じFSFという組織を説明する文章の中で第二の条件は「ソースコードへの完全なアクセスと改変する自由」となり、長らくGNU’s Bulletinに掲載され続けることになった。これが変化するのは1996年7月号である。ここで「third, the freedom to distribute a modified version and thus help build the community.」(第三に、改変されたバージョンを頒布する自由であり、それによってコミュニティの形成を助ける自由である)という一節が加わり、改変後の頒布について触れられるようになった。当時は現在につながるLinuxディストリビューションや様々なプロジェクトが大きく台頭し始めた頃であり、その成長を意識していたのではないかとは推測している。そして、この1996年頃にGNUプロジェクトの情報配信はwww.gnu.orgでのWeb提供へと徐々に移行を始め、この「三つの自由」がWhat is Free Software?というページで常時公開されるようになった。

これが自由ソフトウェアの定義とされるものがWeb上で公開されるまでの経緯であるが、長期の間において自由ソフトウェアとは何であるかという点を明確に示す文書が常時分かる状態ではなく、またGNUの哲学やコピーレフトの思想が目立つことでそれらに隠れた状態であったことは確かだろう。さらに、1990年代の中頃はRichard StallmanによるX ConsortiumやBSDといったパーミッシブなライセンスを支持する勢力への攻撃的な文書が目立つ場所に置かれていたこともあり、その傾向に拍車をかけていたとも考えられる。

Debianのフリーソフトウェア

ここで自由なソフトウェアの定義の歴史はDebianへ移る。Debianプロジェクトは1993年にIan Murdockによって開始された。彼はDebian Manifestoという文書を作成し、その中でDebianはLinuxとGNUの精神に則り、誰でも自由に利用可能なソフトウェアのみで構成し、オープンで民主的な組織でLinuxディストリビューションを作り上げることを企図することを宣言していた。ここで自由の原則に触れられたと考えられるが、ただし、その自由の定義がされていたわけではない。

このようなDebianの思想とGNUとしてのLinuxディストリビューションの必要性により、翌年の1994年からDebianはFSFの支援を受けることになり、0.9系時代までのDebian GNU/LinuxディストリビューションはFSFにおいても頒布が行われた。Ian MurdockもGNUプロジェクトのメンバーとなり、この時期のDebianはFSFの関係組織であったとみなすこともできるだろう。しかし、このFSFとDebianプロジェクトとの蜜月は、1996年3月にDebianのリーダーがIan MurdockからBruce Perensに代替わりすることで終了した。Bruce PerensはDebianの独立性を重視し、リーダーとなって早々にFSFからの支援を打ち切ったのである。

そして、DebianとFSFとの関係が途切れた翌年の1997年、Debian開発者のEan SchuesslerがあるイベントでRed Hat社の社員らと行った議論の中で事件が起きた。Ean Schuesslerが、Red Hatが会社を拡大していくことで考え方が変わる可能性を危惧し、コミュニティに対してフリーソフトウェアの理想にコミットし続けることを保証する文書を出すべきだろうという提案をRed Hat側の人々へ行った所、Red Hatの創業者であるBob Youngが「That would be the kiss of death.」(それは死のキスだ)と答えたのである。

Bob Youngにとってはそのような制約が将来の利益を生み出す能力を狭めるかもしれないとその場で漠然と考えたのだと思われるが、Debian開発者らにとっては単純な話ではなく、自分達のDebianの思想が変質化しないことをどのように保証するかを考えさせられることになった。この直後から一ヶ月の間にBruce Perensと当時のDebian開発者らの侃侃諤諤な議論が行われ、1997年7月、コミュニティに対して完全に自由なソフトウェアの提供を続ける約束であるDebian社会契約(Debian Social Contract)が策定された。そして、このDebian社会契約を定めるにあたり、この契約でのDebianプロジェクトとしてフリーソフトウェア(Free Software)とは何であるかを明確化するため、同時にDebianフリーソフトウェア・ガイドライン(DFSG)も策定されたのである。

このDFSGの公開後、Debianの組織内に留まらず、フリーソフトウェアの範囲を指し示す定義としてDFSGは広まり始めた。当時自由なソフトウェアを頒布する中心的なサイトとして利用されていたSunSiteでは、即座にSunSiteでの受け入れ基準としてDFSGを採用するということも起きた。このような普及があったのは、Debianプロジェクトが基本的にはLinuxディストリビューションのプロジェクトであり、Linuxディストリビューションが様々な自由なライセンスが付与されたソフトウェアの複雑な集合体であることにも起因するだろう。ライセンスに個々の哲学や思想が含まれていたとしても、コミュニティが自由と考えるソフトウェアを過不足なく、かつ矛盾なく自由なソフトウェアの集合物として扱える基準をDFSGは示したのである。

なお、Debian社会契約とDFSGの策定の議論の間、FSFによる「三つの自由」が参照されたことはないと考えられ、リーダーのBruce Perensもその存在を認識していなかった。また、Bruce PerensはDFSGの策定後にその内容をRichard Stallmanへメールで送付しているが、その返答は「this is a good definition of Free Software.」(適切な自由ソフトウェアの定義である)と返ってきただけとされている。もし、DebianとFSFの関係が希薄になっていなければDFSGが三つの自由に置き換わっていた可能性も考えられるが、これらの時系列を考えると当時はRichard Stallman自身も明確には自分たちが自由ソフトウェアの範囲を定義しているという自覚を持っていなかった可能性もあるだろう。

オープンソースの定義へ

DFSGが策定された1997年はEric Raymondが「伽藍とバザール」を発表した年でもある。Linuxが徐々に一般にも認知され始め、自由なソフトウェアを志向するコミュニティの中には様々な企業もその中へ取り込んでいくことを模索する人々も現れた。

ここからの流れは拙作の「オープンソースの誕生」https://shujisado.com/2017/05/17/612085/ に繋がるので詳しくは書かないが、先ず1998年2月3日にVA Linux Systems社において行われた会議でFree SoftwareをOpen Sourceという用語で代替していく方針が決められた。この会議にはVA Linux Systemsの面々、Foresight Institute、Linux InternationalからJohn “maddog” Hall、SUSE、そしてEric Raymondが加わっていたとされている。そして、当日中にその方針がBruce Perensへ連絡され、2月9日までにDFSGから固有名詞を入れ替える形でオープンソースの定義が策定された。その後、4月7日に自由なソフトウェアを代表する人々が集められたサミットが開催され、投票でOpen Sourceという用語を使用する方針が採択された。この時の出席者は、Tim O’Reilly、Eric Raymond、Linus Torvalds、Brian Behlendorf(Apache)、Larry Wall(Perl)、Guido Van Rossum(Python)、Eric Allman(Sendmail)、John Gilmore(Cygnus Solutions), Michael Tiemann(Cygnus Solutions)等である。

以降のオープンソースという用語の受容は敢えてここで書くようなことはないが、当時の自由なソフトウェアに対する期待と用語の考案、定義付け、主要関係者による承認というプロセスが全て別々の場所と人で進められたというある意味でのドラマ的な展開はその後の受容にとって良い影響を与えたのだろう。

四つの自由と自由ソフトウェアの定義化

オープンソースという用語が爆発的に世間に広まっていく中、FSFとRichard StallmanはこのFree Softwareと基本的には同じ領域を指すと考えられる新しい用語に対し、しばらくは距離感を測りかねていた。しかし、オープンソースという用語が広まる中で、自分達が自由ソフトウェアというソフトウェアの区分を明確に定義していなかったことも認識したのだろう。翌年の1999年までにはFSFはオープンソースという用語ではFSFの考える自由の哲学が伝わらないと判断し、オープンソースとは一線を引いた立場であることを明確にするようになった。

そのような中で、さりげなく「三つの自由」だけを示していたWhat is Free Software?のページは大幅に書き直され、自由ソフトウェアの定義と呼べる内容に改められた。そして、三つの自由の前に「The freedom to run the program, for any purpose (freedom 0).」(目的を問わずプログラムを実行する自由 (第零の自由))が加えられたのである。この時点で現在の「Four Freedoms」(四つの自由)であるフリーソフトウェアの定義がほぼ確定し、細かく修正が加えられているものの現在もそれが維持されている。

ここまでが、実質的に同じ自由な状態を指し示すカテゴリを意味する用語として、四つの自由による自由ソフトウェア、DFSGによるフリーソフトウェア、オープンソースの定義によるオープンソースという三つの定義と名称が存在することになった流れである。ソフトウェアのカテゴリの範囲を指し示す定義としての違いは実用的にはないのではあるが、背景となる思想には差異はある。今後、自由と不自由の境界について考えなければならない時がやってくるだろうと考えられるが、そのような時には歴史を振り返ることで正しい道が見えてくるだろう。

注意

本稿では、Free Softwareの訳語として自由ソフトウェアとフリーソフトウェアを意図的に使い分けている。FSFに依拠する文脈では自由ソフトウェアを使用し、Debianに依拠する文脈ではフリーソフトウェアを使用している。

参考

new UNIX implementation (net.unix-wizardsへのRMS投稿)：
https://groups.google.com/g/net.unix-wizards/c/8twfRPM79u0/m/1xlglzrWrU0J
GNU Manifesto：
https://www.gnu.org/gnu/manifesto.en.html
GNU’s Bulletin 1986年2月号：
https://www.gnu.org/bulletins/bull1.txt
History Roundtable Discussion @ Debconf4, June 2004：
https://gabriellacoleman.org/debian-history-roundtable-discussion/
Debian Social Contract / Debian Free Software Guidelines：
https://www.debian.org/social_contract.en.html
オープンソースの誕生：
https://shujisado.com/2017/05/17/612085/

付録2：オープンソースと自由ソフトウェアの違い

オープンソースという用語は自由ソフトウェア(Free Software)という用語を置き換えるために作られたのは周知の事実である。それならば、両者の意味する所は全く同じであるはずであるが、歴史的経緯により両者には別々にその言葉の定義が存在する。それぞれの用語を代表する組織であるFree Software Foundation(FSF)とOpen Source Initiative(OSI)は各々の定義の維持に心血を注いでいるが、実際の所、この両者の違いというものは存在するのだろうか？

四つの基本的な自由

どんな目的に対しても、プログラムを望むままに実行する自由 (第零の自由)。
プログラムがどのように動作しているか研究し、必要に応じて改造する自由 (第一の自由)。ソースコードへのアクセスは、この前提条件となります。
ほかの人を助けられるよう、コピーを再配布する自由 (第二の自由)。
改変した版を他に配布する自由 (第三の自由)。これにより、変更がコミュニティ全体にとって利益となる機会を提供できます。ソースコードへのアクセスは、この前提条件となります。

FSFでは自由ソフトウェアであるための条件として上記の「Four Freedoms」(4つの自由)を定義している。第一から第三までの自由が1999年まで使用された自由ソフトウェアの定義とほぼ同一内容を指す条文であるが、ここでは著作権的な考え方としては複製権、翻案権、二次的著作物作成権、頒布権に関して無制限の許諾を意味すると考えられる。

特殊であるのは「第零の自由」(Freedom 0)である。この条項はオープンソースの定義が誕生後に追加されたのであるが、入手したソフトウェアの実行という著作物の使用行為の自由を定義している。第一から第三までの自由は権利者の著作権による独占権に依拠しているが、第零の自由は、著作権としては基本的に自由に使用できる領域に自由を定めているのである。プロプライエタリなソフトウェア業界では実行行為に対しても契約で制限を加えることが長く慣行として根付いているのでここで自由を定義することは不自然ではないのだが、複製、翻案、頒布といった利用行為に自由が定められているのであれば定義としてはそれで十分であるように一見考えられる。ただ、FSFではこの第零の自由を「どんな人間や組織でも、あらゆるコンピュータシステム上で、どんな種類の仕事と目的のためにでも、開発者や特定の団体と連絡する必要なく、プログラムを使うことができるという自由」と説明しており、非常に幅広い意味を持つ条項として位置付けている。

オープンソースの定義との比較

オープンソースの定義は十箇条で構成されるが、それぞれの条項は下記のように区分することができる。

第一条から第三条 – 著作権における各支分権の利用許諾に焦点：

第一条 (自由な再頒布)：無制限で自由な再頒布を規定
第二条 (ソースコード入手性)：ソースコードへ容易にアクセスできることを規定
第三条 (改変と派生著作物作成)：自由な改変と派生著作物の作成の保証と同一ライセンスでの頒布の許可を規定

第四条以降 – 技術面を含むより広範な原則を明確化：

第四条 (ソースコードの完全性)：元のソースコードの完全性を維持する作者の権利と改変の自由とのバランスを取る
第五条から第十条：個人やグループ、あるいは用途等のおいて差別がなく、技術的に中立で何ら制限もない広範な原則を明確化

これを前述のFSFの四つの自由と比較すると、基本的にオープンソースの定義の第一条から第三条までは四つの自由の論理の組み立て方は異なるものの著作権的なコンテキストでは複製権、翻案権、二次的著作物作成権、頒布権に関して無制限の許諾を意味すると考えて問題ないだろう。すなわち、四つの自由における第一から第三までの自由と同一の内容を規定していると考えて良いと考えられる。なお、第四条に関しては第三条までの内容を補完するものであるが、これも第三までの自由に含まれると考えられる。

そして、オープンソースの定義の第五条から第十条までの内容に関しては、特に実行行為(使用行為)に絞っているわけではないのだが、第五条や第六条での個人や組織あるいは利用目的での差別の禁止に顕著な同一性があるように、ほぼ四つの自由における第零の自由に該当するものと考えて良いだろう。実際の所、自由なライセンスを判別するための審査基準として考えるとオープンソースの定義とFSFの四つの自由は特に差異はなく、結果としては同じような判定になる。

両者の差異

オープンソースの定義と四つの自由には厳密に検証すれば差異がある可能性はあるが、多くのオープンソース関係者は実務上は差異がないと考えている。細かな差異があるとすれば、下記のようなものだろう。

ライセンス判定基準としての違い：

オープンソースの黎明期においてライセンス判定上において自由ソフトウェアと最も大きな差異とみなされていたのはPerlのライセンスであったArtistic License 1.0だと考えられる。OSIはArtistic License 1.0をオープンソースとして設立当初から認めていたが、FSFは「あまりにも曖昧過ぎる。いくつかの文章はそれらに期待される目的には手が込みすぎ、意味は不明瞭」という理由で自由ソフトウェアのライセンスとして認めていない。これはFSFが厳格過ぎるというわけではなく、ごく初期のOSIには厳格なライセンス審査のプロセスが存在せず、オープンソースを全く新しい概念の運動として扱おうとする一部の者の恣意的な判断が介入する余地があったからだと佐渡は考えている。

ごく初期のOSIは少数のオープンソースの偉人らによる極めて小さな組織でしかなかったが、現在のOSIはより開かれた中立的組織に変貌しており、ライセンス承認のプロセスには開発コミュニティだけでなく世界中の法曹関係者もボランティアで関与するようになっている。ライセンスには法的な明確性、一貫性が求められるようになっており、Artistic License 1.0のようなライセンスが提出された場合、問題なく承認されるということはないだろうし、最低でも明確化のための条文修正が求められるのではないかと推測される。

現在のOSIのライセンス承認プロセスにおいてはFSFの自由ソフトウェアの判定と差異が出ることは基本的にはないと考えられるが、逆にOSIによるオープンソースの判定の方が厳密になっている領域もある。特許に関する条項やパブリックドメイン等である。

基本的にオープンソースのライセンスは著作権の許諾であるが、特許条項が存在するライセンスもある。著作権で許諾されている利用が特許権で妨げられるのであれば本末転倒なわけであるので特許権の許諾をついでに行うことは望ましいわけであるが、逆に特許権を許諾しないとライセンスに書かれていた場合にどうなるだろうか？これはCreative CommonsのCC0 1.0のOSIによる審査で問題となった事例であるのだが、CC0では特許権が「許諾されず、その他の影響を受けることもない」とわざわざ書かれているのである。OSIの承認プロセスにおける議論では、このような条項はソフトウェア特許に対するユーザーの防御を弱める可能性があるとの意見が出され、それに同調する意見が一定数存在したことから承認という結論は出せなかった。一方、FSFにおいては特許条項において懸念を示し、ソフトウェアに使用することを推奨してはいないものの自由ソフトウェアのライセンスとして承認している。

パブリックドメインについては、OSIは概ねそれに該当するソフトウェアを実務上はオープンソースの範疇として捉えているように考えられるものの、パブリックドメインとは著作権が存在しないことであるわけなので著作権ライセンスというのが存在することはなく、また法域による解釈の差異があることからパブリックドメイン化することは推奨していない。基本的にはオープンソースと明確に区別していると考えて良いだろう。一方、FSFはパブリックドメインには著作権がないのであるからライセンスは必要とせず、パーミッシブなライセンスと基本的に同じとみなせるという立場を取り、自由ソフトウェアの一部であるとの認識を示している。

哲学の違い：

オープンソースの定義と四つの自由に関して、ライセンス基準としての差異はないもののその解釈の違いによって前述のような差異が発生すると考えられるが、このような解釈差が生まれるのは両者の哲学の違いであるように考えられる。

オープンソースの定義はDebianという主にLinuxディストリビューションを開発するプロジェクトが起源にあるが、様々なライセンスが付与された多くのソフトウェアが漫然と同居するような状況において機能するということが念頭に置かれている。それによって、ソフトウェアの頒布と開発サイクルの法的および実用的側面に主な焦点を当てており、そのことからビジネスフレンドリーな概念としてみなされている。

一方、FSFの四つの自由は、ソフトウェアの自由という哲学的および倫理的側面に重点を置いており、基本的な倫理原則としてユーザーが享受する自由を強調していることから、よりイデオロギーに基づいた概念として見られるのだろう。これはオープンソースの定義の条文があくまで「ライセンスはこのように定義しなければならない」という権利者たる開発者に向けた条文という体裁であるのに対し、四つの自由は頒布を受けたソフトウェアに含まれるべき自由を唱えているという主語の違いからも認識できるだろう。

OSIによるオープンソースの定義とFSFによる四つの自由はどちらも基本的には同じカテゴリのソフトウェアをそれぞれにオープンソースもしくは自由ソフトウェアであると定義していると考えて良い。わずかな解釈の差異や依拠する哲学や倫理に差異はあり、それぞれを支持する勢力はその哲学から支持していることから呼称についても含めて正しく両者の違いは区別されるべきである。ただ、両者はソフトウェアの自由に対処するアプローチは異なるものの、どちらも結局は自由でオープンなソフトウェアを推進しているということは多くの人々が認識すべきことだろう。

付録3：オープンソースは何故パブリックドメインを含まないのか？

著作権関連の話題においてパブリックドメイン(Public Domain、公有)という言葉がしばしば出てくる。このパブリックドメインという言葉は特にソフトウェアの業界では根強く誤解されてきた用語であり、現在では少なくなったもののまだ誤用が見られる言葉でもある。

一言で言えば、パブリックドメインとは「知的創作物において知的財産権が発生していない状態」である。ここでの知的創作物とは人が創作した作品のことであるが、その作品において著作権、商標権、特許権、意匠権等が完全に発生していないことを指している。つまり、全ての知的財産権の帰属を考慮する必要なく、無許諾かつ無制限に作品を利用できることになる。ここでの作品には文学、絵画、映像、音楽そしてプログラム等が含まれる。

作品がパブリックドメインとなるには

知的財産権の枠組みにおいて著作権だけは作品を生み出した段階にて自然に発生し、かつベルヌ条約に加盟する全法域においてその権利が相互に保護されるグローバルな権利として定められている。他の知財権と比較すれば非常にお手軽かつ創作後もしくは著作者の死後70年といった非常に長期に渡る保護がなされることも特徴であるが、期間があるということは当然ながらその権利保護期間が終了すれば著作権は消滅する。これが、パブリックドメインになるということである。

権利保護期間の終了以外にそもそも最初に生み出された段階でパブリックドメインとなっている作品も存在し、日本を含めた多くの法域では政府が発する法令や通達等の文書は著作権等が発生しないことが多い。また、特にプログラムの作品においては無条件に著作権が発生するわけでなく、誰が書いても同一になるといったプログラム創作物としての要件を満たせないような作品は著作権が発生せず、パブリックドメインであると言えるだろう。

さらに、著作権を放棄してパブリックドメインとすることも法域によっては可能であり、日本では著作者人格権(公表権、氏名表示権、同一性保持権等)が留保されると解されるという問題は残るものの、著作権の放棄が宣言されることで事実上のパブリックドメインとして扱うこともできる。このようなケースをパブリックドメインへの献呈と呼ぶこともあり、その宣言の手法としては昨今ではクリエイティブ・コモンズのCC0を採用することが増えている。作品をCC0で宣言した場合、放棄可能な著作権等の権利を放棄し、放棄できない権利に対しては無条件かつ永続的な利用許諾を行い、利用許諾が無効な場合は権利行使をしないということを確約することになる。

オープンソースとの違い

パブリックドメインはオープンソースと混同されることがあるが、オープンソースはその定義から「著作権が発生した上でその権利に基づいて利用者に対して自由な利用を許諾するライセンスもしくは許諾された状態」を指す用語である。つまり、著作権が存在するかしないかという根本的な部分で両者は全く異なる概念なのである。

ただ、どちらも対象となる作品を自由に利用できるという点においては同一である。このため広い意味においてパブリックドメインはオープンソースの範疇に入ると見做されることもある。実際、Free Software Foundation(FSF)は、ソースコードが入手できることが前提であるがパブリックドメインのソフトウェアを自由ソフトウェアとして分類している。パブリックドメインにあるソースコードは全てにおいて自由であり、FSFの根本的理念である自由とは矛盾しないため、その考え方は理解できるものである。

しかしながら、特にオープンソースのコンプライアンスに関わる者等からはパブリックドメインにはやや否定的な捉え方がされることが多い。何故なら、パブリックドメインに著作権が存在しないということであれば、元々の権利者が作品に対しての制御を完全に失っているからである。

著作権がないということは事実上その作品はもはや誰のものでもない。つまり、財産権も人格権も存在せず、クレジットというものも一切必要がなくなるということだ。また、複製、翻案、改変も完全に自由である。作品を管理する人間というものは存在しないし、それによって形式としては剽窃に該当する行為も当然ながら横行するようになる。MITライセンスなどの寛容なオープンソース・ライセンスであったとしても剽窃にはある程度の対抗手段があるわけだが、パブリックドメインの場合にはそもそも最初から権利がない。ソフトウェアのオープンソース化する際には作品を改善するフィードバックというものも期待されることが多いわけだが、それようなエコシステムの発生は基本的に起こりにくくなる。また、剽窃者によって新たに著作権を主張され、不自由なソフトウェアとされることもあるだろう。新たな実装で何らかの問題が発生したとしても、元の権利者にはそれに対処する手段は何もないのである。

これらの理由のため、オープンソースを使用していく上でのコンプライアンス観点ではリスクが増え、そのためパブリックドメインをオープンソースとは明確に区別する意見は根強い。

なお、Open Source Initiative(OSI)ではパブリックドメインであるソフトウェアを実務上はオープンソースの範疇として考えられることを概ね認めていると考えられるが、OSIが行っていることはオープンソースの定義に合致するライセンスの審査であり、パブリックドメインは著作権がないことからライセンスが存在し得ないため、パブリックドメイン化するような法的条件の文書等を審査することもしないし、ソフトウェアをパブリックドメイン化するのではなく承認されたオープンソースのライセンスを付与することを推奨している。

付録4：無保証と免責の条項

オープンソース定義にはオープンソースであるライセンスで定めるべき条件もしくは定めてはいけない条件が記述されているが、オープンソース・ライセンスと呼ばれるものに必ずのように含まれる条項も存在する。いわゆる無保証と免責の条項である。本稿では、この無保証と免責の条項について雑多に解説する。

免責の必要性

オープンソースのライセンスで記述されている内容は大別すると、著作権表記、許諾内容と条件、無保証と免責の条項となる。著作権表記はライセンスが効力を発揮する前提となる著作権者の証明であり、続く許諾の内容と条件においてオープンソースの定義を完全に遵守する内容を記述していけば基本的にはオープンソースのライセンスとして効力を持つことになる。ということで、無保証と免責の条項はオープンソースであるための必須条件ではないのであるが、このような条項が含まれていることは、歴史的、法的および実務的な理由によって重要な意味を持つ。

歴史的にオープンソースのソフトウェアは営利組織ではなく、個人もしくは非営利組織を主体とするコミュニティの主導によって開発されてきたが、このような営利組織による支援がないということは保証の責任を負う組織が存在しないことを意味している。つまり、オープンソースへの貢献者の多くは保証請求といった法的リスクを負う余裕のないグループの一員であり、免責条項は貢献者を潜在的な責任から保護することになる。

もう少し詳細に書けば、開発者はソフトウェアによって引き起こされた欠陥や損害に対して法的責任を負う可能性があり、使用者は損害が発生した場合に訴訟する権利を持つ。特に個人の貢献者や小規模な組織にとっては経済的に打撃を受ける可能性があるわけであり、このような保証と責任を制限することで法的な影響を恐れることなく、より多くの人々がオープンソースのプロジェクトに貢献することを可能にするのである。

また、一般的にオープンソースによる開発は多くの人々が協働して進化することを目指しているが、このようなスタイルの開発手法を考慮すると、そもそも特定の使用者による特定の目的に対してソフトウェアの適合性を保証することは非現実的であるとも言える。よって、オープンソースのライセンスにおける無保証条項および免責条項は、開発者を法的リスクから保護し、オープンソースのプロジェクトへの広範な参加を促し、オープンソース開発の協働的な性質を維持するために不可欠な要素なのである。

無保証と免責の歴史

免責条項の解説としてはこれで終わりなのだが、さて、このような条項はいつ頃から存在していたのだろうか？ソフトウェア著作権が認められる以前から商用の計算機の世界でこのような条項を含む契約が存在していたと思われるが、オープンソースのライセンスとしては最初期のライセンスであるMITライセンスの初出とされているライセンスにもそれらしき条文が存在する。

M.I.T. makes no representations about the suitability of this software for any purpose.
It is provided “as is” without express or implied warranty.
(MITは、本ソフトウェアがいかなる目的にも適していることを表明するものではありません。
本ソフトウェアは、明示または黙示の保証なしに「現状のまま」提供されます。)

上記は1984年にMITのコンピューターサイエンス研究所において開発されたIBM PC用のTCP/IPスタックを頒布する際に付与された著作権ライセンスの最後の免責条項の部分の抜粋である。短い二つのセンテンスだけであるが、明確に無保証であることを表明していることが分かる。当時は米国でソフトウェアに著作権が認められることが確定した頃であるが、著作権のライセンス料を徴収しても大した金額にならないという判断から一方的な許諾(ライセンス)とされたという経緯がある。つまり、自由に使っていいが保証はしない、ということであり、現代の協働的な発想とは直接的に結びつかないわけであるが、現在のライセンスで一般的な”as is”はここに源流がある。

GNU Emacs is distributed in the hope that it will be useful, but without any warranty. No author or distributor accepts responsibility to anyone for the consequences of using it or for whether it serves any particular purpose or works at all, unless he says so in writing.
(GNU Emacsは有用であることを期待して頒布されていますが、いかなる保証もありません。GNU Emacsの作者も頒布者も、使用した結果について、あるいは特定の目的を果たすかどうか、あるいは全く機能しないかどうかについて、文書でそう述べない限り誰に対しても責任を負いません。)
GNU Emacs copying permission notice(1985)

翌年の1985年、Richard StallmanがGNU Emacsの頒布のために付与したGNU Emacs copying permission notice(GNU Emacs複製許可通知)にも同様の条項が存在する。このGNU Emacsに付与された通知こそが1989年のGNU GPL version 1に繋がるライセンスであるが、”as is”は存在しないもののMITの初期型よりも明確に無保証と免責が述べられていることが分かる。

1989年に発表されたGNU GPL version 1においてはほぼ現代の一般的なオープンソースのライセンスに見られるような冗長な免責条項となっている。このGPL version 1もそうなのだが、このあたりからの特徴として免責条項が基本的に大文字で表記されるようになったと考えられる。この特徴的な大文字表記には実はそれなりの意味がある。

米国においては民法および商法は州毎に異なるが、それでは州を越える取引に不都合が発生するということで民間の組織によって合衆国内での統一的な法典が作成された。それが統一商事法典(UCC:Uniform Commercial Code)であり、民間組織作成の法典なのでそれ自身は法的効力を持たないものの、全米のほとんどの州がこの法典の内容をそのまま州法として採用しているために事実上の法として機能している。

何の関係があるのだと思われるかもしれないが、この統一商事法典にて商取引の契約では売主側が免責されると規定するためには目立つように記載しなければならないと定められているのである。単に目立つようにと規定されているので太文字や下線でも構わないような気もするのだが、タイプライターの時代からずっと大文字の慣行となっている。

なお、統一商事法典では契約書で目立たないように免責規定を書いた場合、あるいはそもそも免責を明言して規定しなかった場合は、売主は買主に対して黙示的に保証したことになると定められている。つまり、オープンソースのライセンスの無保証と免責条項にて大文字で表現されていなかった場合、それらの条項は無効と主張することも可能であり、黙示的にソフトウェア製品の商品適格性(品質、性能を備え商品として用途に適合しているか)や特定目的適合性(買主の目的に適合しているか)等の保証をしていると理解される余地を残すのである。

ただし、オープンソースのライセンスは著作権の利用許諾であり、商取引の契約ではない。しかしながら、厳密に既存の法との適合性を持たせるように努力した結果、このような大文字の条文となったのだろう。

付録5：「頒布」という訳語を使用するのは何故か？

オープンソースに限らずソフトウェア業界においては、distributeもしくはdistributionという単語を使用することが多い。そして、その単語への日本語訳としては「配布」を割り当てることが多いだろう。しかしながら、オープンソースの定義やオープンソース・ライセンスの日本語訳等では基本的にdistributeの訳として「頒布」という語が使用されている。これは何故だろうか？

はいふ【配布】
［名］(スル)配って広く行き渡らせること。「駅前でちらしを―する」
はんぷ【頒布】
［名］(スル)品物や資料などを、広く配ること。「希望者に無料で―する」「銘酒の―会」

デジタル大辞泉を引用すると配布と頒布は上記のような意味となる。違いがあるようには見えるが、どちらも「何かを広く配って行き渡らせる」という意味で違いはない。では何が違うのか？実は「配布」は基本的に無償であり、「頒布」は無償もしくは有償のどちらの場合もあり得るという違いがある。上記の用例でのチラシは無償であり、銘酒頒布会というのは有償の即売会のことを意味するのである。

自明ではあるがオープンソースの定義や全てのオープンソース・ライセンスにおいては無償か有償かという点は問わない。そうであるにも関わらず、オープンソース関連の文脈においてdistributeを「配布」と訳すと、まるで「ソフトウェアを広く配って行き渡らせる」行為が無償であることに限定する印象を与えることになる。だから、「頒布」という訳語が使用されるのである。我々の自由なソフトウェアのコミュニティは、無償に限定されるように捉えられるということを一貫して否定してきたわけでもあり、正しい理念を伝達していくためには誤解されにくい言葉を使用する方が望ましい。

冒頭の疑問についてはこの回答で終わるはずなのだが、この議論は忘れられた頃に繰り返される話の一つであり、私は認識していなかったが数年前にもそれなりに大きな論争があったらしい。それらの論争において「配布」で良いとする主張する側の論拠は基本的にパターン化されているので、下記で反証していく。

「頒布」という言葉が難しすぎる：
確かに「頒布」という言葉は日常的に使うことは少なく、やや難解な日本語に該当するのだろう。ただ、それは「配布」よりも難しいというだけのことであり、Googleで検索すれば一般的に販売会のような意味で頒布会という言葉が一般的に使用されている事実に気が付くだろう。また、同人誌の界隈では太古の昔から販売会のことを頒布会と呼んでいるようである。コミックマーケットにおいても基本的に「頒布」という言葉が使われている。同人誌業界での「頒布」という用語の使用には歴史的な事情があるようであるが、「頒布」が難しすぎるのであればここまで広く使われないのだから、少なくともこの用語は一般の人々に受けいれられていると考えて良いだろう。

日本の著作権法で定める「頒布権」と混同するし、貸与の意味がある：
日本国の著作権法では「頒布権」という権利が定められている。ややこしいことにこの権利は映画著作物に限定されている権利である。映画館での上映フィルムを配給元から制御するための権利を何故か本邦では頒布権という名称にしたのであるが、オープンソース・ライセンスは著作権に依存しているので、この映画の頒布権との区別するために頒布という言葉を使ってはならないという主張があるわけである。

正直ここまでくると言いがかりに過ぎないのだが、著作権法第二条一項十九号において「頒布」という言葉の意味が「有償であるか又は無償であるかを問わず、複製物を公衆に譲渡し、又は貸与すること」と先に定義されていることをその主張は忘れている。頒布は著作物を広く公衆に譲渡もしくは貸与することと定められているのであれば、すなわちこれはオープンソース・ライセンスにおけるdistributeの意味として完全に正しいだろう。このように明確に定義され、意味としても合致する言葉の使用を否定する理由にはならないだろう。

ここまできてもさらに「オープンソースを貸与するという行為は通常ないので頒布は正しくない」という空虚な主張も過去にあったらしい。このような主張はかつてソフトウェアがテープ、MO、フロッピー等のデバイスに固定化され、回覧されていた歴史を忘れているのだろう。また、最近であれば、クラウドのサービスはその形態によってソフトウェアの貸与があり得るだろう。つまり、ソフトウェアは貸与できるし、オープンソースも然りである。オープンソースのライセンスであれば、複製、翻案、頒布の自由が許諾されているわけだが、この許諾された権利の中に暗黙的に貸与という利用行為への許諾も含まれていると考えて良いのである。

結論として、オープンソース・ライセンスが絡みそうな文脈ではdistributeは極力「頒布」と訳すことを勧める。「配布」の場合はどうしても無償に偏ることになり、有償のケースを除外しかねない。かつて自由ソフトウェアの陣営が、Freeは無償を意味するという誤解を中々払拭できなかった歴史を認識すべきだろう。

出自：
本稿は、2023年3月3日に佐渡によって書かれた「「配布」と「頒布」の違い」を一部修正した文書である。

付録6：倫理を振りかざすライセンスが好ましくないのは何故か？

オープンソースが社会で受容されるにつれ、コミュニティの中においても一定の倫理が求められる傾向が強まっている。Code of Conduct(行動規範)を定める開発プロジェクトが多くなったのもその流れだろう。しかしながら、ライセンスにおいて使用者に対して倫理的な行動を求めることは現在に至っても忌避されており、それを悪だと看做す人々も多い。これは何故だろうか？

嫌いな奴を排除する

大抵の人には嫌いな人がいるものだ。人間とはそのようなものだろう。その嫌いな人々に自分が開発したソフトウェアを使わせたくないという感情を持つことを中々否定できるものではない。そして、ソフトウェアの開発者には開発したソフトウェアに対する著作権が帰属する。著作権に基づいて第三者に対しソフトウェアの利用の許諾を宣言する行為がライセンシングであるわけなので、このライセンスにて「〇〇の集団と〇〇に属する連中は一切使用禁止」と記述すれば嫌いな奴を排除できる。厳密な法的効力の問題は残るが、それでもライセンスとしてはそれでも有効なライセンスとして扱われるだろう。

ということで、昨今の風潮を踏まえれば、様々な領域における「悪人」を排除するといった正義のためにライセンシングの手法を使いたいと思う人が出てくるのは仕方がない。マイノリティを保護もしくは支援したいとか、戦争やテロの脅威を無くしたいとか様々な正義感からくる倫理的と考える思想をライセンスに込めたくなるのは理解できる。しかし、このような倫理をライセンスを込める手法は、ライセンサー側の期待通りに事が運ぶことはまずなく、むしろ想定しなかった害が発生することが多い。

利用者が困るライセンシングの実例

例を出していこう。かなりの昔となるが、Debianプロジェクトにてあるアナログ電子機器用ツールのライセンスが問題となったことがあった。それは「南アフリカ警察の使用を禁ずる」という内容が含まれるライセンス条文だった。おそらくは人種差別政策として名高いアパルトヘイトに抗議する意図があったのだろう。しかし、問題が発覚した当時は既にアパルトヘイトは終結し、南アフリカの警察には黒人警官が一般的となっていた時代だった。つまり、ライセンサーの開発者は差別される黒人を憐んで正義のためにライセンスを書いたのだと思われるが、逆に南アフリカの黒人警官を差別する結果となっていたわけである。

日本に目を移すと、Javaの黎明期に開発された分散オブジェクト関連のツールがあり、そのライセンスには「平和的な目的のために使用してください。軍隊や兵器関連、防衛行為関連、反社会的活動のために使用してはいけません」という記述が存在した。この記述の意図は分かる。平和は尊いものだ。大抵の人々が願うものだろう。しかし、自分の使い方は本当に「平和的な目的」での使用なのだろうか？あるいは本当に軍事利用や反社会活動に完全に繋がっていないのだろうか？という疑問に対して確信を持って否定できる人はどれほどいるのだろうか？そもそも平和的な目的というのはあまりにも曖昧な表現ではあり、もっと簡潔な軍事目的の禁止というだけであったとしても、現在進行中の戦争を見れば意図せず日本の民間企業の技術が使われていることも分かるだろう。ソフトウェアサプライチェーンがグローバルの隅々にまで行き渡った現在においては、ソフトウェアの用途というものは最後まで誰にも分からないケースが多々ある。そのような中で用途で制限をかける非常に難しいのである。

他に有名な用途縛りの事例としてはある音声認識ツールがある。このツールのライセンスには、「原子力関連、航空管制その他の交通関連、医療、救急関連、警備関連その他人の生命、身体、財産等に重大な損害が発生する危険を有するシステムに使用してはいけません」という記述が含まれている。これは正義感というよりも単にミッションクリティカル領域での使用に自信がないだけかもしれないが、このライセンスではヘルスケアや金融サービスといった領域でのサービスで使用することができないことになるだろう。単に自信がないなら「無保証」を強調すれば良いだけの話だ。

オープンソースであるために

これらの前述の例のようにライセンスで使用できる者や利用用途の制限を加えることは、ソフトウェアを使用する側に混乱をもたらすだけでなく、開発者側にとっても普及という点で大きなハンデを負うことになる。良いことと言えばライセンサーである開発者自身の自己満足ぐらいであり、これはある意味で非常に大切かつ重要なのではあるものの、オープンソースではこのような考え方をライセンスに含めることは明確に禁止している。これらの事例はオープンソースの定義における第五条、第六条に反するわけだが、このような条項が設けられたのはまさに上記の事例のようなことを避けるためなのである。

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

利用する分野(fields of endeavor)に対する差別の禁止
ライセンスはある特定の分野でプログラムを使うことを制限してはなりません。例えば、プログラムの企業での使用や、遺伝子研究の分野での使用を制限してはなりません。

https://opensource.jp/osd/osd19/#5

中には、単にオープンソースもしくは自由ソフトウェアと称するよりも倫理的な行動を求める方が重要であると反論する方がいるかもしれない。しかしながら、オープンソースとはどうすればソフトウェアを効率よく伝搬させ、健全なエコシステムを作り上げることができるかという命題を突き詰めた結果でもあり、今日のソフトウェアのサプライチェーンにおいて中心的な考え方でもある。ここにある種の例外を持ち込むことはその例外を含むソフトウェアの使用の忌避を招き、結局のところソフトウェアは普及が妨げられ、ライセンサーが意図する正義や倫理が広く伝わることもないという事象を招くことになる。

今日の倫理を求める勢力

上記のような反論を世界中から指摘されても、ある種の信念を持っているタイプの人達は自分の信じる正義を追求することもあるもので、Organization for Ethical Source (OES)が提唱するHippocratic Licenseという倫理の塊のようなライセンスが数年前に一部で話題となった。このHippocratic Licenseの3条には奴隷制、強制労働、児童労働、拷問や非人道的扱いや罰、基本的人権侵害行為、個人のプライバシー妨害、民族弾圧、労働者団結権および結社権の行使妨害等の行為を禁止する他、性別、性的指向、人種、民族、国籍、宗教、カースト、年齢、障害等での差別も完全に禁止し、同一労働同一賃金も求められるという条項が含まれている。

このHippocratic Licenseを推進する人々には本当に強い信念があるのだろう。このプロジェクトを推進する中心的な方は多くのオープンソースプロジェクトが採用するContributor Covenantという標準的Code of Conduct(行動規範)の作者でもあり、この成功体験からライセンスにおいても信念を持ち続ければ普及すると考えているのではないかと思う。

しかしながら、既に幾つかの事例で述べてきたことと同様の理由でこのライセンスが普及することはないだろう。著作権ライセンスは制約が多いほど使われることが少なくなるが、ここまで詰め込めば好んで採用する者は中々いない。結局はある種の社会運動の象徴的な枠割を果たすということになるのだろう。

倫理を条件にすることは避けよ

そもそもライセンスとは著作権を保持する者が第三者に対して行う一方的な許諾の宣言に過ぎない。契約性が議論されることがあるが、厳密にはライセンスは契約ではないのである。ソフトウェアの使用者側はそのライセンスにサインすることもないわけであり、ある意味では性善説的な部分を含有するシステムである。そもそも広く許諾を与えている状況において倫理的条件への違反をライセンサー側が証明しなければならないというのは途方もない作業である。どこかの組織がソフトウェアを軍事利用しているか、あるいは反社会的活動に手を染めていないか等をどうやってライセンサー側が証明できるのだろうか？これではライセンスの条文としては全く機能していないと言えるだろう。

自分達が考える倫理的な行動をユーザーにも求めるのは問題ない。GNU GPLの前文にはFSFとしての御託が書いてあるが、GPLの本文の条件にはそのような御託はなく単に一般的な条件だけが述べられている。GPLが示しているように、何かの倫理的な主張をするのは問題ないが、それをライセンスにおいて許諾条件にしてはならない。ライセンスが依拠する著作権法で倫理を追求するのは著作権の限界を超えており、世の中における不正な行為や望ましくない行為は著作権法以外の法で縛るべきである。

また、そもそもライセンスを遵守しようという意識が持つ人々は相対的に倫理的にも高い水準にあると考えられるが、倫理意識に乏しい組織や人がわざわざライセンスを遵守しようとするだろうか？ソフトウェアが必要であれば黙って使うか、あるいは言い訳できる仕組みを用意するだけだろう。ライセンスという仕組みは悪用したい者にとっては何の制約にもならないものであり、ライセンスに倫理を持ち込んで複雑にすればするほど、善意の人々は混乱し、悪意の人々が得をすることになる。

これが倫理をライセンスに持ち込んで条件にすることが好ましくない理由である。