オープンソースライセンス

オープンソースライセンス（英: open-source license）は、ソフトウェアやそのソースコード、ブループリント、設計書の利用、修正、頒布を認めるソフトウェアライセンスの総称である^[1][2]。「広義のオープンソースソフトウェア」に課せられる「ソフトウェアライセンス」を指し、オープンソースのライセンス、フリーソフトウェアのライセンスを包括する。

オープンソースライセンスは、オープンソースソフトウェアの性質上、ソフトウェアやその二次著作物は元の作者でも制御しきれない形で頒布されるため、ソフトウェアは「有用であるとは思うが無保証である」のような但し書きを基本的な誓約として含んでいる^[3]。ライセンスによっては、作者名や著作権名を表示する誓約（著作権表示条項）や、ソースコードを改変して再頒布する場合は同じライセンスで配布する誓約（コピーレフト条項）が存在する^[4][5]。

オープンソース・イニシアティブ^[6]、フリーソフトウェア財団^[7]、Fedora^[8]、Debian^[9]はオープンソースライセンスとして適切であるとされるライセンスを精査している^[10]。オープンソースライセンスの一例としてApache-2.0、MIT、GPLv3、CDDL-1.0がある^[11]。

オープンソースライセンスは、ライセンサー（作者）の定めた誓約に従う範囲でライセンシー（利用者）にソフトウェアとソースコードの自由な利用を認める。多くのライセンスで作者がソフトウェアおよびソースコードを「無保証（NO WARRANTY）」と宣言した誓約を記し^[3]、それに加えてライセンス毎に異なる誓約（条項、条文）が記される。

オープンソースライセンスは、オープンソースソフトウェアの性質上、ソフトウェアやその二次著作物は元の作者でも制御しきれない形で流通し、作者がその品質を保証することは難しいため、基本的な誓約として「有用であるとは思うが無保証である」と定めている^[3]。つまり、作者はソフトウェアが作者および利用者の予期した動作をする／しないの保証をしない。また、その動作の結果何らかの損害を利用者にもたらしたとしても、作者はその瑕疵担保責任を保障しない。

著作権表示条項は、適切な形でソースコードや付属文書に含まれる著作権表示を保持し、つまり二次的著作物を作った者が自分で0から作ったように偽らないことを定める^[4]。ソースコードを伴わないバイナリ形式だけでの配布を認めているライセンスでは、その際にも付属文書に著作権表示を記載するように定めているものもある。

著作権表示は全てのソースコード上に記載される作者名や、ソフトウェアのプロジェクトパッケージ内のCOPYRIGHTファイル、エンドユーザーが閲覧可能なアプリケーション上の表示などがある。ソースコード上の著作権表示をエンドユーザーが確認することは難しく、アプリケーション上の著作権表示をエンドユーザーが確認することはたやすい。著作権表示でどの程度までの利用者が閲覧可能な表示をするかは個々のライセンスに依る。

同程度条件のライセンスであるApache-2.0とMITでは、Apache-2.0はエンドユーザーへの著作権表示条項を含み、MITはエンドユーザーへの著作権表示条項を含まない。

コピーレフト条項は、そのライセンスで公開されたソフトウェアを修正して二次創作物として公開する場合に、同じライセンスもしくはそれと同等条件の利用許可を要求するライセンスで公開することを定める^[5]。あるソフトウェアがパブリックドメイン以下で公開されて他のユーザーは自由に利用できていたものが、そのソフトウェアを企業や大学（研究機関）が改変した二次著作物を独自のライセンスの元で公開して他のユーザーが自由に利用できなくなることを抑制することが出来る^[5]。一方で、企業や大学（研究機関）としては改変にまつわる技術革新による利益を得ることが出来なくなるため、コピーレフトライセンスには否定的である^[12]。

コピーレフト条項は、GNU General Public License（GPL）が代表的である。GPLのソースコードをBSDライセンスのソースコードと組み合わせて新しいソースコードを作った場合、GPLのコピーレフト条項によって、このソースコードを頒布する際にはGPLでの利用を認め、ソフトウェアの元となる全てのソースコードの開示が必須となる。

原作者特権条項は、原則的には利用者にその事項を許可もしくは禁止するが、原作者が利用する場合にはその限りではない条項である。原作者特権は、現在ソースコードを独占的に所有している企業がそれをオープンソース化するに当たって考慮する余地のあるものである。Mozillaのためのライセンスとして作成されたMPLでは、二次著作物を頒布する際にはソースコードを公開しなくてはならないが、元々のMozillaの著作権を有していたNetscape Communicationsだけは特別であって、二次著作物のソースコードを公開しなくてもよい権利をもっている。

オープンソース・ライセンスはオープンソース・イニシアティブ（OSI）が承認したオープンソースのソフトウェアに課するソフトウェアライセンスの総称である。

オープンソース・イニシアティブは「オープンソースの定義」に基づいて、ソフトウェアのソースコードの利用者（個人および団体）の目的（営利および非営利）を問わず利用、修正、再頒布を認めるライセンスをオープンソース・ライセンスとして承認している^[13]。オープンソース・ライセンスとして主要なソフトウェアライセンスの一覧を公開しており^[11]、ソフトウェアがオープンソースを冠する場合はこの承認されたライセンスを課すことを推奨している^[14]。

フリーソフトウェアライセンスはフリーソフトウェア財団（FSF）が承認したフリーソフトウェアに課するソフトウェアライセンスの総称である。

フリーソフトウェア財団は「フリーソフトウェアの定義」に基づいて、利用者のソフトウェアを実行、複製、頒布、学習、改善する自由を尊重するライセンスをフリーソフトウェアライセンスとして承認している。フリーソフトウェアに課すに適したライセンスの一覧を保守し^[16]、一覧にはフリーソフトウェアライセンスに適合しているか、コピーレフト条項を含むか、GNU GPLと互換性があるか、および特記事項を記載している。

Fedoraは同プロジェクトのソフトウェアに課せられるべきソフトウェアライセンスの一覧を管理している^[8]。

Fedoraの公式パッケージに含まれるソフトウェアはこの一覧にあるソフトウェアライセンスが課せられたものであり、これらのライセンスはフリーソフトウェア財団、オープンソース・イニシアティブおよびRed Hat法務担当が公認したものである^[17]。公認ライセンスはFedoraのメーリングリストで公に検証されており、過去に議論されたライセンスの適正判断や、新規に一覧に追加を求めるライセンスの検証要望などを受け付けている^[18]。ただし、コンフィデンシャルな情報を送ることや、ソースコードについての法的な助言を求めるために利用してはならないし、メーリングリストの参加者が法律家や弁護士であることを仮定するべきではない。

DebianはDebianフリーソフトウェアガイドライン（DFSG）に準拠したソフトウェアライセンスの一覧を管理している^[9]。

Debianの公式パッケージに含まれるソフトウェアは原則としてDebianフリーソフトウェアガイドラインに準拠したソフトウェアライセンスが課せられたものであり、そのガイドラインはソフトウェアの利用者によるソースコードの利用、修正、再頒布が認められていることを求めている。Debianフリーソフトウェアガイドラインに準拠したソフトウェアライセンスの課せられたソフトウェアはオープンソースソフトウェアの定義に符号するものであり、DFSG準拠ライセンスはオープンソースソフトウェアに課すソフトウェアライセンスの一例として参考にできる。

パブリックドメインにソフトウェアのソースコードを置くことは、その成果物の製作者の著作権を放棄する手段の一つである。パブリックドメイン以下に公開されたソースコードは全ての権利が放棄されていると見なし、利用者はそのソースコードおよびソフトウェアの利用、修正、再頒布が可能である^[19]。パブリックドメインと同等の条件でソフトウェアやソースコードを頒布するライセンスとしてCC0^[20][21]、Unlicense^[22][23]、WTFPL^[24][25]などが存在する。

オープンソースライセンスにおけるパブリックドメインの著作権の放棄は著作権法の下に完全に認められたという実績（判決）は存在しておらず、法的な判断が不明瞭である^[26]。オープンソース・イニシアティブはパブリックドメインの著作権の権利放棄の不確定性からオープンソースと承認しない判断を出している^[27][28]。フリーソフトウェア財団はCC0をパブリックドメインにソフトウェアのソースコードを置く手法として推奨し^[29][30]、他のライセンスも承認している^[16]。

パブリックドメインにソースコードが置かれている場合はソースコードおよびソースコードから生成されるソフトウェアの利用、修正、再頒布は可能であるが、パブリックドメインにソフトウェアのみが置かれている場合はその限りではない^[31]。この場合、ソフトウェアの権利の放棄は想定されるが、そのソフトウェアのソースコードの権利の放棄は想定できず、ソースコードを利用、修正、再頒布の可否は別途考えなければならない。

また、日本の著作権法では著作物に対しては著作者人格権が付随すると考えられており，その権利には保護期間が無い（つまり永続である）。

オープンソースライセンスはデュアルライセンスで用いられることがある。デュアルライセンスのオープンソースソフトウェアを利用する場合、利用者は課せられたオープンソースライセンスのいずれかを一つだけ選択して、選択したライセンスの課せられたオープンソースソフトウェアとして利用する。オープンソースソフトウェアにデュアルライセンスを課す主な用途は二種類あり、一つはソフトウェアを用いたビジネスモデル、一つはライセンスの互換性である。

尚、3つ以上の種類のライセンスから選択できるものをマルチライセンスという。

オープンソースライセンスには著作権表示条項の強弱が異なるライセンスがあり、一つのソフトウェアにそれらのライセンスを併用してビジネス上のメリットを享受するためにデュアルライセンスを利用する。著作権表示条項の強弱の異なるオープンソースライセンスをデュアルライセンスとして課したソフトウェアで利用者が著作権表示条項の強いライセンスを選択してソフトウェアを利用した場合、利用者は著作権表示条項に基づきソフトウェアの名称やソフトウェアのソースコードの配布場所を二次利用者（エンドユーザー含む）に伝える義務を伴う。ソフトウェアの開発者（開発元）にとっては利用者が善意の広告塔となり、ソフトウェアの名称や配布場所を多数の人に知ってもらう機会を得ることができる。なお、利用者が著作権表示条項のないライセンスを選択してソフトウェアを利用することもできるため、必ずしも利用者が広告塔となりうるわけではない。例としては、著作権表示条項の強いApache Licenseと著作権表示条項の弱いMIT Licenseのデュアルライセンスがある。

ソフトウェアライセンスにはライセンスの互換性の有無があり、互換性のないライセンスが課せられたソフトウェアは併用することが出来ない。そのようなライセンスの互換性の課題を回避するためにデュアルライセンスを利用する。ソースコードの利用時に同一のソフトウェアライセンスを課すことを要求する条項があるライセンスが課せられたソフトウェアと併用する場合、その条項に基づき自身の開発したライセンスは同一のソフトウェアライセンスを課さなければならない。しかしながら、そのような条項がないライセンスが課せられたソフトウェアと併用する場合、自身の開発したソフトウェアライセンスは他のものを採用することができる。利用者がどのようなライセンスが課されたソフトウェアと併用するか、利用者が二次開発するソフトウェアにどのようなライセンスを課すか、などのソフトウェアライセンス採用選択の幅を広げる。例としては、コピーレフト条項のあるGPLとコピーレフト条項のないMITのデュアルライセンスがある。

オープンソースソフトウェア開発において自身のソフトウェアが課するライセンスの選定、およびソフトウェアが利用するソースコードのライセンスの検証は重要である。

「自身のソフトウェアが課すライセンス」はそのソフトウェアの「ソースコードに課すライセンス」であるが、オープンソースソフトウェアのためのライセンスは多数存在しており、ソフトウェア開発の手段や目的、ソースコードの利用者に課すべき制約に合わせて適切なライセンスを選択しなければならない。ソフトウェアのソースコードの利用、修正、再頒布を認めるオープンソースソフトウェアとしての定義の遵守の他、広告条項の付与、コピーレフト条項の付与、著作権の放棄などを考慮すべきである。ソフトウェア利用者のライセンスの解釈を検証する労力を減らすため（ライセンスの氾濫を防ぐため）、オープンソースソフトウェアには独自のライセンスを作成、適用するのではなく既存のライセンスから選択することが望ましい。

「ソフトウェアが利用するソースコードのライセンス」はモジュールとして利用するソフトウェアの各個ライセンスについて検証しなければならない。Apache Licenseのように広告条項が含まれている場合は、広告条項に基づいてソースコードリポジトリのCOPYRIGHT、LICENSEファイルに利用しているソフトウェアの名前を連ねる必要があったり、ソフトウェアの利用者が必ず閲覧できる箇所にソフトウェアの名前を表示させなければならない。GNU GPLのようにコピーレフト条項が含まれている場合は、コピーレフト条項に基づいて自身のライセンスを決定し、自身のソフトウェアで使っている他のソフトウェアとのライセンスの互換性を検証しなければならない。

ライセンスの互換性は特に注意すべきで、ソフトウェアが利用するソースコードにライセンスの互換性がない場合、そのソースコードおよびソフトウェアを利用することは出来ない。例えば、「GNU GPLでソースコードの公開が必須となるオープンソースソフトウェア」と「商用契約でソースコードの開示を禁じられたプロプライエタリソフトウェア」を併用しようとした場合、GNU GPLを遵守すると商用契約に違反し、商用契約を遵守するとGNU GPLに違反することになる。

2000年代前半、オープンソースソフトウェアのライセンスは多数の独自ライセンスが策定され、よく似た条文で一部分だけ異なるという有象無象のライセンスがいたずらに作られていったことを問題視し、その事象はライセンスの氾濫と呼ばれ批判の対象となった^[33]。ライセンスの氾濫はライセンス製作者の虚栄心を満たすだけの無害なものではなく、オープンソースソフトウェアに課せられたライセンスの内容を精査しなければならない利用者を疲弊させる有害なものであった。オープンソース・イニシアティブは2006年にこの問題を解決するためライセンス氾濫問題プロジェクト（License Proliferation Project）を立ち上げ^[34]、ライセンスレビューを通して承認ライセンスを選定することでライセンスの氾濫を抑えた歴史がある^[35]。ライセンスの氾濫を再発させないため、オープンソースソフトウェアのライセンスは既存のオープンソースライセンスを採用することが推奨される^[11][36]。ライセンスの作成者は新規ライセンスの必要性について慎重な検討を経て策定に至り^[37]、ライセンスを承認する団体は新規のライセンスが既存のライセンスと本質的な差異がない場合は承認しない判断を下している^[38]。

ライセンスの継承条文を伴うオープンソースライセンスが課せられたソフトウェアは、その継承条文に基づき、ソフトウェアのソースコードを利用、修正したソフトウェアのソフトウェアライセンスを同等条件のものとするよう縛る。このライセンスの縛りはソースコードの二次利用、三次利用と伝播し、ライセンスがウイルスのように感染していくことからウイルス性ライセンス（ライセンス感染）と呼ばれる^[39]。

ウイルス性ライセンスは二次利用ソースコードのライセンスを同一のものに強制することでライセンスの氾濫を防ぐ効力がある。一方で、二次利用ソースコードおよびそのソフトウェアのライセンスを選択する権利を失い、課せられるライセンスの内容に依っては、広範囲のソースコードを開示の強制や、非営利以外の利用が禁止されるなどの利用上の制約を伴う恐れがある。

ライセンス感染するライセンスの例としては、GPL (コピーレフト条文)やCC BY-SA (SA条項)がある。ライセンス感染の影響は元となったソフトウェアライセンスの内容に依るが、GNU GPLのコピーレフト条項のようにソースコードの公開を義務とするものや^[5]、CC BY-SAのSA条項ように同等条件のライセンスを強制するだけ（ソースコードの公開を求めるかどうかは別条文に依る）のものがある^[40]。

パブリックドメインにソフトウェアのソースコードを置くことは、その成果物の製作者の著作権を放棄する手段の一つである。パブリックドメイン以下に公開されたソースコードは全ての権利が放棄されていると見なし、利用者はそのソースコードおよびソフトウェアの利用、修正、再頒布が可能である。パブリックドメインと同等の手段として、ソフトウェアのソースコードに課すツール、ライセンスとしてのCC0、WTFPLなどが存在する。パブリックドメインにソースコードが置かれている場合はソースコードおよびソースコードから生成されるソフトウェアの利用、修正、再頒布は可能であるが、パブリックドメインにソフトウェアのみが置かれている場合はその限りではない。この場合、ソフトウェアの著作権の放棄は想定されるが、そのソフトウェアのソースコードの著作権の放棄は想定できず、ソースコードを利用、修正、再頒布する権利は別途考えなければならない。

パブリックドメインによる著作権の放棄は著作権法の下に完全に認められたという実績（判決）は存在しておらず、法的な判断が不明瞭である^[41]。ソースコード作成者が著作権を放棄する意図でパブリックドメイン以下で公開していたソースコードに対して、ソースコード作成者が考えを変えて著作権の保持を主張してソースコードの二次利用者を訴えた場合に、サブマリン特許のように見解を翻して権利を行使することの是非という道徳的な観点は別として、著作権の放棄の有効性について著作権法の下にどのような判断がなされるのか明確になっていない。つまり、パブリックドメインはソースコード作成者の当初の意図に反して著作権の放棄はできておらず、著作権の保持を根拠にしたソースコードの二次利用者に対する訴えは有効であるとされる可能性がある。

そのような不確定性のため、オープンソース・イニシアティブはパブリックドメインに相当するCC0を有効なオープンソースライセンスとして承認していない^[27]。一方で、フリーソフトウェア財団はCC0を有効なフリーソフトウェアライセンスとして承認している^[30]。パブリックドメインおよびそれに類するライセンスの著作権の放棄の有効性の疑義は著作権の放棄を条文に加えている一部のライセンスのみの課題であり、著作権の放棄について言及していないラインセンスでは著作権は放棄されていないものとして見なして疑義の課題とはならない。

オープンソースライセンスは、ライセンサーとライセンシーの間の契約だけではなく、著作権法および関連法案等にの下に法的拘束力を持ち、ライセンスを違反することは著作権法を違反することと同義である。

2003年3月7日、UNIXおよびLinuxのソフトウェアを開発していたSCOグループは、同社が権利を持つUNIXのソースコードに基づく機能をIBMが同社の開発するLinux関連製品に不正に組み込んだとして、IBMを提訴した^[42]。IBMはこれに対してSCOグループを反訴した。同様にSCOグループはIBM以外のNovellやRed HatのLinuxディストリビューションベンダーも訴えた^[43][44]。

2006年2月27日、Debianプロジェクトのバグトラッキングシステムにオープンソースライセンスで頒布されているFirefoxの商標の扱い、およびメンテナンス方法に関する指摘が挙げられ^[45]、ライセンスの誓約に沿っていないため「Firefox」の商標を用いて再頒布すべきではないという報告された。DebianはFirefoxのソースコードを修正したソフトウェアを「Firefox」ではなく「Iceweasel」の名称で頒布することに決定した。

2006年、GNUプロジェクトは、TiVoが開発するLinuxをOSに用いたハードディスクレコーダーがGPLv2に違反して利用者の自由を妨げていることを指摘し、TiVo化という単語を作り批判、論争した^[46]。GNUプロジェクトはGPLv3でTiVo化を認めない誓約をライセンス条文に組み込んだ。

2008年、オープンソースライセンスは重要な法的マイルストーンを通過した。アメリカ合衆国連邦裁判所がオープンソースライセンスは著作権のある成果物の使用において明確に法的拘束力の条件を設定すると判決を出し^[47]、それゆえに著作権法の下で強制力を持つことが明示された。オープンソースソフトウェアのソフトウェアライセンスの法的拘束力の有無はそれ以前には明確には判断されておらず、この訴訟でも下級裁判所の判決はArtistic Licenseは法的拘束力を持たず、ライセンス条項を無視することは著作権侵害ではないと判決を出していた。

2018年2月現在、広く使われている、もしくは、著名なコミュニティが採用しているオープンソースライセンスの一覧を以下に示す^[11]。

主要なオープンソースソフトウェアのライセンス

ライセンス名	略称	OSI承認	FSF承認	GPL互換性	コピーレフト
Apache License 2.0	Apache-2.0	[11]	[48]	[48]	[48]
修正BSDライセンス（三条項BSDライセンス）	BSD-3-Clause	[11]	[49]	[49]	[49]
二条項BSDライセンス	BSD-2-Clause	[11]	[50]	[50]	[50]
GNU General Public License, version 3	GPLv3	[11]	[51]	[注釈 1]	[51]
GNU Lesser General Public License, version 3	LGPLv3	[11]	[52]	[52]	（weak）[52]
MIT License（X11 License）	MIT	[11]	[53]	[53]	[53]
Mozilla Public License 2.0	MPL-2.0	[11]	[54]	[54]	（weak）[55]
Common Development and Distribution License version 1.0	CDDL-1.0	[11]	[56]	[56]	（weak）[57]
Eclipse Public License 2.0	EPL-2.0	[11]	[58]	[58]	（weak）[58]
Creative Commons Attribution 4.0 license	CC BY		[59]	[59]	[59]
Creative Commons Attribution-Sharealike 4.0 license	CC BY-SA		[60]	[60]	[60]
Creative Commons Zero	CC0	[27]	[30]	[30]	[30]

クリエイティブ・コモンズ・ライセンスは、「作品」の利用許諾を与える非常に汎用的なライセンスであるが、ソフトウェア（オープンソースソフトウェア）に用いるライセンスとしては適していない。クリエイティブ・コモンズはオープンソースソフトウェアのライセンスは、クリエイティブ・コモンズ・ライセンスではなく、オープンソース・イニシアティブもしくはフリーソフトウェア財団の提示するライセンスの利用を推奨している^[61]。

クリエイティブ・コモンズ・ライセンスは「作品」の著作権に主観に作られており、ソフトウェアとソースコードの2つの「作品の関係」、および、「作品の動作」についてはライセンスで言及されていない。クリエイティブ・コモンズ・ライセンスをオープンソースライセンスとして用いようとした場合、基本的な誓約である「無保証（NO WARRANTY）」条文がないため、他のライセンスの併用もしくは同ライセンスの変更を共にして用いなければならない。

シェアードソースライセンスは、ソフトウェアのソースコードを開示し、利用者にソースコードおよびソフトウェアの動作の参照およびデバッグのための利用を認めることを目的としたライセンスである^[62]。利用者にソースコードの利用を認めている点ではオープンソースライセンスと同様であるが、利用目的に制限的であり必ずしもオープンソースソフトウェアに用いることができるライセンスではない。

シェアードソースライセンスは、マイクロソフト、ソニー・インタラクティブエンタテインメントなどがソフトウェアの公開に使用している。マイクロソフトのシェアードソースライセンスは幾つかの種類があり^[63]、制約の緩やかなライセンスはオープンソース・イニシアティブ公認のオープンソースライセンスであるが^[64]、制約の厳しいライセンスは同社との提携契約の上でソースコードの参照のみが許されるライセンスである。Sony Computer Entertainment of America（SCEA）は2005年にPlayStationのソフトウェアのためにSCEA Shared Source Licenseを設けていた^[65][66]。

クローズドソースライセンスは、「オープン」の対義語としての「クローズ」を用いて、「オープンソースライセンス」の対義語としてプロプライエタリソフトウェアのライセンスの総称として使われることがある^[67][68][69]。ただ、オープンソースソフトウェアとクローズドソースソフトウェアがソフトウェアを完全に二分するわけではないので、「オープンソースライセンスではないソフトウェアライセンス」が「クローズドソースライセンス」というわけではない。ソースコードの公開、利用を有償とするクローズドライセンスのソフトウェアは、オープンソースソフトウェアではなくプロプライエタリソフトウェアと呼ばれる^[70]。

ポータル FLOSS

• ソフトウェアライセンス
• オープンソースソフトウェア

• Open Source Initiative Licenses & Standards
• Free Software Foundation Various Licenses and Comments about Them
• Debian License information
• Fedora Licensing:Main