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

出典: フリー百科事典『ウィキペディア(Wikipedia)』
Jump to navigation Jump to search

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

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

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

誓約[編集]

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

基本的な誓約[編集]

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

著作権表示条項[編集]

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

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

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

コピーレフト条項[編集]

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

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

原作者特権条項[編集]

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

カテゴリ[編集]

OSI オープンソース・ライセンス[編集]

OSI公認ライセンスのロゴ

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

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

FSF フリーソフトウェアライセンス[編集]

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

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

Fedora Licensing List[編集]

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

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

DFSG準拠ライセンス[編集]

DebianDebianフリーソフトウェアガイドライン(DFSG)に準拠したソフトウェアライセンスの一覧を管理している[9]

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

パブリックドメイン[編集]

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

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

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

デュアルライセンス[編集]

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

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

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

ライセンスの課題[編集]

ライセンスの互換性[編集]

オープンソースライセンスライセンスの互換性、矢印が一方的な互換性を表す[32]

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

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

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

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

ライセンスの氾濫[編集]

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

ウイルス性ライセンス[編集]

CC BY-SAパブリックドメインを合わせた時にSA属性によりCC BY-SAが強制されるライセンス感染の例

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

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

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

パブリックドメインの有効性[編集]

パブリックドメインであることを表す万国著作権条約3条に基づくマーク

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

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

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

法的判断[編集]

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

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

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

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

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

主要なライセンス[編集]

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

主要なオープンソースソフトウェアのライセンス
ライセンス名 略称 OSI承認 FSF承認 GPL互換性 コピーレフト
Apache License 2.0 Apache-2.0 Yes[11] Yes[48] Yes[48] No[48]
修正BSDライセンス(三条項BSDライセンス) BSD-3-Clause Yes[11] Yes[49] Yes[49] No[49]
二条項BSDライセンス BSD-2-Clause Yes[11] Yes[50] Yes[50] No[50]
GNU General Public License, version 3 GPLv3 Yes[11] Yes[51] N/A Yes[51]
GNU Lesser General Public License, version 3 LGPLv3 Yes[11] Yes[52] Yes[52] Yes(weak)[52]
MIT License(X11 License) MIT Yes[11] Yes[53] Yes[53] No[53]
Mozilla Public License 2.0 MPL-2.0 Yes[11] Yes[54] Yes[54] Yes(weak)[55]
Common Development and Distribution License version 1.0 CDDL-1.0 Yes[11] Yes[56] No[56] Yes(weak)[57]
Eclipse Public License 2.0 EPL-2.0 Yes[11] Yes[58] No[58] Yes(weak)[58]
Creative Commons Attribution 4.0 license CC BY No Yes[59] Yes[59] No[59]
Creative Commons Attribution-Sharealike 4.0 license CC BY-SA No Yes[60] No[60] Yes[60]
Creative Commons Zero CC0 No[27] Yes[30] Yes[30] No[30]

関連するライセンス[編集]

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

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

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

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

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

脚注[編集]

  1. ^ Brief Definition of Open Source Licenses”. Open Source Initiative. 2013年4月25日閲覧。
  2. ^ Popp, Dr. Karl Michael (2015). Best Practices for commercial use of open source software. Norderstedt, Germany: Books on Demand. ISBN 978-3738619096. 
  3. ^ a b c Pieter Gunst (2015年8月15日). “Open Source Software: a legal guide”. LawGives. 2018年3月8日閲覧。 “Most open source licenses do not provide any warranties, but instead will provide the software "AS IS."”
  4. ^ a b Dennis Clark (2015年12月4日). “OSS Attribution Obligations”. nexB. 2018年3月8日閲覧。
  5. ^ a b c d What is Copyleft?”. Free Software Foundation (2018年1月1日). 2018年2月9日閲覧。
  6. ^ Open Source Initiative. “Licenses & Standards”. 2018年2月9日閲覧。
  7. ^ GNU Project. “Various Licenses and Comments about Them”. 2018年2月9日閲覧。
  8. ^ a b Fedora (2017-11--06). “Licensing:Main”. 2018年2月9日閲覧。
  9. ^ a b Debian (2018年2月4日). “License information”. 2018年2月9日閲覧。
  10. ^ United States Department of Defense (2009年10月16日). “Defining Open Source Software (OSS)”. 2018年2月9日閲覧。 “Careful legal review is required to determine if a given license is really an open source software license. The following organizations examine licenses; licenses should pass at least the first two industry review processes, and preferably all of them”
  11. ^ a b c d e f g h i j k l m Open Source Initiative. “Open Source Licenses by Category”. 2018年2月9日閲覧。
  12. ^ Dave Crossland (2011年6月17日). “Copyleft Business”. 2018年2月9日閲覧。
  13. ^ Open Source Initiative. “Licenses & Standards”. 2018年2月8日閲覧。
  14. ^ Open Source Initiative. “What is "Open Source" software?”. 2018年2月9日閲覧。
  15. ^ Wheeler, David A. (2015年). “The fight for freedom”. 2018年2月9日閲覧。
  16. ^ a b GNU Porject (2018年2月10日). “Various Licenses and Comments about Them”. 2018年2月9日閲覧。
  17. ^ Fedora. “Licensing:Main Overview”. 2018年2月20日閲覧。 “This list is based on the licenses approved by the Free Software Foundation , OSI and consultation with Red Hat Legal.”
  18. ^ Fedora (2017年11月6日). “Discussion of Licensing”. 2018年2月15日閲覧。
  19. ^ Categories of free and nonfree”. GNU Project (2018年1月1日). 2018年3月5日閲覧。 “If the source code is in the public domain, that is a special case of noncopylefted free software.”
  20. ^ CC0”. Creative Commons. 2018年3月2日閲覧。
  21. ^ Creative Commons Tools”. Digital Curation Centre (2014年11月25日). 2018年3月5日閲覧。
  22. ^ Unlicense Yourself: Set Your Code Free”. 2017年2月28日閲覧。
  23. ^ Joe Brockmeier (2010年1月11日). “The Unlicense: A License for No License”. OStatic. 2017年5月18日閲覧。
  24. ^ Sam Hocevar. “WTFPL 2.0”. sam.zoy.org. 2011年4月1日閲覧。
  25. ^ OSI Board Meeting Minutes, Wednesday, March 4, 2009”. Open Source Initiative (2009年3月4日). 2013年4月3日閲覧。 “[...] the following licenses to be discussed and approved/disapproved by the Board. [...] WTFPL Submission: [...] Comments: It's no different from dedication to the public domain. Author has submitted license approval request -- author is free to make public domain dedication. Although he agrees with the recommendation, Mr. Michlmayr notes that public domain doesn't exist in Europe. Recommend: Reject”
  26. ^ webmink (2017年7月28日). “Public Domain Is Not Open Source”. 2018年2月25日閲覧。
  27. ^ a b c OSI Board Meeting Minutes, Wednesday, March 4, 2009” (2009年3月4日). 2018年2月9日閲覧。
  28. ^ Public Domain Is Not Open Source”. Open Source Initiative (2017年7月28日). 2018年2月9日閲覧。
  29. ^ Using CC0 for public domain software”. Creative Commons (April 15. 2011). 2011年5月10日閲覧。
  30. ^ a b c d e GNU Project (2018年2月10日). “CC0”. 2018年2月9日閲覧。
  31. ^ Categories of free and nonfree”. GNU Project (2018年1月1日). 2018年3月5日閲覧。 “In some cases, an executable program can be in the public domain but the source code is not available. This is not free software, because free software requires accessibility of source code.”
  32. ^ The Free-Libre / Open Source Software (FLOSS) License Slide by David A. Wheeler on September 27, 2007
  33. ^ Martin Michlmayr (2008年8月21日). “OSI and License Proliferation”. 2018年2月9日閲覧。
  34. ^ Open Source Initiative. “The Licence Proliferation Project”. 2011年5月10日閲覧。
  35. ^ Open Source Initiative. “The Licence Review Process”. 2018年2月8日閲覧。
  36. ^ GNU Project (2018年1月1日). “How to choose a license for your own work”. 2018年2月9日閲覧。
  37. ^ Common Development and Distribution License (CDDL) Description and High-Level Summary of Changes”. sun.com. 2005年2月14日時点のオリジナルよりアーカイブ。2018年3月25日閲覧。
  38. ^ OSI Board Meeting Minutes, Wednesday, March 4, 2009”. Open Source Initiative. 2011年4月1日閲覧。 “It's no different from dedication to the public domain. ... Recommend: Reject”
  39. ^ Speech Transcript - Craig Mundie, The New York University Stern School of Business” (2001年5月3日). 2005年6月21日時点のオリジナル[リンク切れ]よりアーカイブ。2011年2月7日閲覧。
  40. ^ Share Alike”. Creative Commons. 2017年8月13日閲覧。
  41. ^ webmink (2017年7月28日). “Public Domain Is Not Open Source”. 2018年2月25日閲覧。
  42. ^ Ladies and Gentlemen, SCO v. IBM Is Officially Reopened”. Groklaw (2013年6月15日). 2014年9月17日閲覧。
  43. ^ SCO's Complaint In the Third Judicial District Court of Salt Lake County, State of Utah” (2004年1月20日). 2018年2月24日閲覧。
  44. ^ Archived copy”. 2004年6月11日時点のオリジナルよりアーカイブ。2004年8月2日閲覧。
  45. ^ Mike Connor (2006年2月27日). “Uses Mozilla Firefox trademark without permission”. 2018年2月24日閲覧。
  46. ^ John Sullivan (2006年2月8日). “[Info-gplv3] “GPLv3 Update #2””. Free Software Foundation. 2011年4月27日閲覧。
  47. ^ Maggie Shiels (2008年8月14日). “Legal milestone for open source”. 2018年2月9日閲覧。
  48. ^ a b c GNU Project (2018年2月10日). “Apache License, Version 2.0”. 2018年2月9日閲覧。
  49. ^ a b c GNU Project (2018年2月10日). “Modified BSD license”. 2018年2月9日閲覧。
  50. ^ a b c GNU Project (2018年2月10日). “FreeBSD license”. 2018年2月9日閲覧。
  51. ^ a b GNU Project (2018年2月10日). “GNU General Public License (GPL) version 3”. 2018年2月9日閲覧。
  52. ^ a b c GNU Project (2018年2月10日). “GNU Lesser General Public License (LGPL) version 3”. 2018年2月9日閲覧。
  53. ^ a b c GNU Project (2018年2月10日). “X11 License”. 2018年2月9日閲覧。
  54. ^ a b GNU Project (2018年2月10日). “Mozilla Public License (MPL) version 2.0”. 2018年2月9日閲覧。
  55. ^ Mozilla. “MPL 2.0 FAQ”. 2018年2月9日閲覧。 “The MPL is a simple copyleft license.”
  56. ^ a b GNU Project (2018年2月10日). “Common Development and Distribution License (CDDL), version 1.0”. 2018年2月9日閲覧。
  57. ^ Rami Sass. “Top 10 Common Development and Distribution License (CDDL) Questions Answered”. 2018年2月9日閲覧。 “The CDDL is considered a weak copyleft license.”
  58. ^ a b c GNU Project (2018年2月10日). “Eclipse Public License Version 2.0”. 2018年2月9日閲覧。
  59. ^ a b c GNU Project (2018年2月10日). “Creative Commons Attribution 4.0 license”. 2018年2月9日閲覧。
  60. ^ a b c GNU Project (2018年2月10日). “Creative Commons Attribution-Sharealike 4.0 license”. 2018年2月9日閲覧。
  61. ^ Creative Commons FAQ: Can I use a Creative Commons license for software?”. Creative Commons (2018年3月7日). 2018年3月8日閲覧。
  62. ^ Shared Source Initiative”. Microsft. 2018年2月15日閲覧。 “the Shared Source Initiative Microsoft licenses product source code to qualified customers, enterprises, governments, and partners for debugging and reference purposes”
  63. ^ Stephen R. Walli (2005年3月24日). “Perspectives on the Shared Source Initiative”. 2018年2月15日閲覧。
  64. ^ Mary Jo Foley (2007年10月16日). “Microsoft gets the open-source licensing nod from the OSI”. 2018年2月15日閲覧。
  65. ^ SCEA Shared Source License 1.0”. Sony Computer Entertainment Inc. (2005年). 2007年1月2日時点のオリジナルよりアーカイブ。2018年2月14日閲覧。
  66. ^ Software License List”. Fedora (2017年11月6日). 2018年2月14日閲覧。
  67. ^ Michael (Monty) Widenius; Linus Nyman (2013年6月). “Introducing “Business Source”: The Future of Corporate Open Source Licensing?”. 2018年2月9日閲覧。
  68. ^ Open Source and Closed Source”. 2018年2月9日閲覧。
  69. ^ Nemesis2k2. “Basic closed-source license? - GDNet Lounge - GameDev.net”. 2018年2月9日閲覧。
  70. ^ Q: What are antonyms for open source software?”. United States Department of Defense (2009年10月16日). 2018年2月9日閲覧。

関連項目[編集]

外部リンク[編集]