GNU Lesser General Public License

出典: フリー百科事典『ウィキペディア(Wikipedia)』
移動先: 案内検索

テンプレート:Infobox software license GNU Lesser General Public License(以前は、GNU Library General Public Licenseだった)または GNU LGPL、単にLGPLは、フリーソフトウェア財団(Free Software Foundation、以下FSFと略称)が公開しているコピーレフト型のフリーソフトウェアライセンスである。八田真行による日本語訳ではGNU 劣等一般公衆利用許諾書と呼称している。

概要

以前の名前から分かる通り、これは他のプログラムにリンクされることを前提としたライブラリのためのライセンスとして作成された。当ライセンスは、強いコピーレフト(strong copyleft)を持つライセンスであるGNU General Public LicenseすなわちGPLBSDライセンスMIT Licenseのようなテンプレート:仮リンクとの妥協の産物として設計されている。LGPLが最初にその略称を示していたGNU Library General Public Licenseは1991年に公開され、GPLv2との対等性を表すため同じバージョン2が付されることとなった。のちに小規模な改訂によりバージョン2.1という小数点リリース(ポイントリリース)となり、1999年に公開されたが、同時にライブラリにこのライセンスを利用すると限るべきではないというFSFの立ち位置を反映させるため、GNU Lesser General Public Licenseと改名された。LGPLv3は2007年に公開された。これは、GPLv3と完全な互換性があり、GPLv3にいくつか追加的(許諾)条項Additional permissions。GPLv3第7項で許されている。)を加えた相補的形式を採用している。よって以前のバージョンよりも条文はかなり簡略化されており、GNU GPLv3への参照が条文に頻繁に現れる。しかしこれはGPLリンク例外を採用しているその他ソフトウェアよりも若干要件は多い。次のセクション"GPLとの違い"を参照。

LGPLはLGPLに従う限り、プログラム自身にコピーレフトの「保護」(立ち位置が異なるものからは、「制限」とも言われるが)を与えるが、単にLGPLで保護されたプログラムとリンクする、他のソフトウェアへこれら「制限」を適用することはない。しかしながら、当該ソフトウェアへ影響を与えるある種のその他の「制限」は存在する。

LGPLは主にソフトウェア・ライブラリに採用されるが、スタンドアローンなアプリケーションにも採用されるいくつかの例が存在し、もっとも有名な例は、MozillaOpenOffice.orgである。

GPLとの違い

GPLとLGPLの主な相違点は、後者が、フリーソフトウェアプロプライエタリ・ソフトウェアかどうかに関わらず、非(L)GPLなプログラムにリンクされ得る(ライブラリの場合は「そのようなプログラムによって利用され得る」)というものである[1][2]。この非(L)GPLプログラムはそれが二次的著作物(derivative work)ではない場合、任意の条項のもと頒布(distribution; 配布)してもよい。二次的著作物である場合は、LGPLv2.1第6節またはLGPLv3第4項の条項により、「顧客(カスタマー)自身の利用のための改変ならびにそのような改変をデバッグするためのリバースエンジニアリング」を許諾する必要がある[3]。これは、GPLのように常に二次的著作物を同一の許諾条項に置くライセンスとは異なり、常に同一の許諾条件に置くとは限らないことを示している。LGPLなプログラムを利用する著作物が二次的著作物か否かは法的な問題である[注釈 1]。ライブラリに動的リンク(すなわち共有ライブラリダイナミックリンクライブラリなどによるリンク)する単体の実行ファイルは、法的に二次的著作物ではないと解釈される可能性がある[注釈 2]。その場合、ライブラリにリンクするプログラムは、LGPLv2.1における第5パラグラフ(Section 5. 第5節)、または同等の内容のLGPLv3第4項(Section 4.)に定義されている「ライブラリを利用する著作物」に該当する。次の文はLGPLv2.1第5節の第1段落にある条文の引用である。

A program that contains no derivative of any portion of the Library, but is designed to work with the Library by being compiled or linked with it, is called a "work that uses the Library". Such a work, in isolation, is not a derivative work of the Library, and therefore falls outside the scope of this License.[4]

LGPL の一つの特徴は、(LGPLv2.1では第3節、LGPLv3では第2項の条項により)ソフトウェアのLGPLで保護された任意の部分をGPLで保護することも可能にさせる。この 特徴により、GPLで保護されたライブラリやアプリケーションにおいて、LGPLで保護されたコードを直接再利用することや、また、プロプライエタリなソ フトウェア製品に利用されないようにするコードのバージョンを作成したいと考える場合、有益となる。

ライブラリのライセンスにGPLとLGPLのどちらを選択するか

以前の名前が"GNU Library General Public License"だったこともあり、FSFはライブラリはLGPLを採用することを望んでいるという印象を受ける人は多かった。1999年2月リチャード・ストールマンは、Why you shouldn't use the Lesser GPL for your next library[1](なぜ次のライブラリには劣等GPLを利用するべきでないのか[2])という評論を執筆し、この中でなぜこのことが当てはまらないケースがあるのかということと、LGPLをライブラリに適用することは必ずしも適切とは限らないことを説明した。

Which license is best for a given library is a matter of strategy, and it depends on the details of the situation. At present, most GNU libraries are covered by the Library GPL, and that means we are using only one of these two strategies [allowing/disallowing proprietary programs to use a library], neglecting the other. So we are now seeking more libraries to release under the ordinary GPL.[1]

このことは、LGPLがテンプレート:仮リンクなのではなく、単に、LGPLを全てのライブラリに適用するべきではないと述べており、例えばGNU CライブラリはLGPLを利用するべきライブラリの一例として引き合いに出されるが、LGPLである理由は標準Cライブラリなどをはじめとするライブラリの実装が既に幾つか存在し、プロプライエタリ・ソフトウェアからなる著作物が、GPLなライブラリを飛び越えて、競合するBSDライセンスなどの緩やかなフリーソフトウェアライセンスにより許諾されるライブラリとリンクする可能性が単に存在するからである。— ストールマンは続けて次のことを主張している。

Using the ordinary GPL is not advantageous for every library. There are reasons that can make it better to use the Lesser GPL in certain cases.[1]

事実、ストールマンとFSFは時折、(利用者の自由を拡大するため、)戦略的事項として、意外なことだが、LGPLより制限の少ないライセンスの利用を強く主張している。有名な例は、Vorbis音声コーデックプロジェクトのライブラリにBSD形式のライセンスを採用したことをストールマンが支持したというケースである[5][注釈 3]

プログラミング言語による特異性

本ライセンスの条文は、C言語やその近縁言語により作成されたアプリケーションを主に意図している用語の使われ方が見られる。Franz Inc.は、Lispのコンテキストにおいて用語を明確化するため、当ライセンスに同社が独自に作成した前文(preamble)を加えた形で公開した。この独自の前文が付記されたLGPLは時折LLGPLと呼ばれる[6]

加えて別の事例として、Adaジェネリクスという特別な性質を持つ言語であり[注釈 4]、このことに対応するためGPLの改変版ライセンスMGPLが作成されている。

「継承」にまつわるLGPLの話題

LGPLで保護されたソフトウェアが非(L)GPLコードにより継承する場合、オブジェクト指向クラスの適合性について若干の懸念が惹起している。明確な説明がGNUの公式ウェブサイト上に与えられている。

The LGPL contains no special provisions for inheritance, because none are needed. Inheritance creates derivative works in the same way as traditional linking, and the LGPL permits this type of derivative work in the same way as it permits ordinary function calls.[7]

参考訳

LGPLは、継承についての特殊な規定を含めていない。なぜなら、何も必要とされないからである。継承は、古きよきリンクと同じ方法で二次的著作物を作成する。そして、LGPLが通常の(訳注: ライブラリの)関数呼び出しを許諾しているのと同様に二次的著作物のこの形式も許諾しているのである。

LGPLの特徴

以上をまとめると概ね次の内容になる。

LGPLは次のことを保証する。この内容はGPLでも保証されている権利の一部である(このことからGPLよりも弱いコピーレフト性を持つ)。

  • 社内など私的組織内部個人で(private)利用するにあたってのソースコード改変、再コンパイルには制限がない。
  • LGPLで頒布されたプログラムを再頒布する際にはソースコードを公開する必要がある。

LGPLで頒布されたライブラリAについて、

  • コンパイル時にライブラリAに(動的静的に関わらずリンクされる可能性のあるプログラムBのソースコードについてはLGPLを適用する必要は無く、その頒布の制限にも関与しない[注釈 5]
  • ライブラリAにリンクしたプログラムBを頒布する場合、Bのライセンスにリバースエンジニアリングを禁止する条項を含めてはならない。(LGPLv2第6節、LGPLv3第4節)[注釈 6]
  • ライブラリAに静的リンクしたプログラムBを頒布する場合、Bのソースコードまたはオブジェクトコードの頒布に制限があってはならない。(LGPLv2第6節a、LGPLv3第4節d0)
  • ライブラリAを改変して作成されたライブラリA'を頒布する場合、A'のライセンスはLGPLまたはGPLである必要がある。

脚注

テンプレート:脚注ヘルプ

注釈

テンプレート:Reflist

出典

テンプレート:Reflist

関連項目

テンプレート:Portal

外部リンク

テンプレート:GNU テンプレート:FLOSSライセンス

テンプレート:FOSS
  1. 1.0 1.1 1.2 1.3 テンプレート:Cite web
  2. 2.0 2.1 テンプレート:Cite web
  3. テンプレート:Cite web
  4. テンプレート:Cite web
  5. テンプレート:Cite web
  6. テンプレート:Cite web
  7. 全文は次の通り。LGPLv2.1を対象に記述されているが、そのページの最上部に記載の通り、LGPLv3では条文の節番号が異なる点を除いて同じ内容が適用され得る。 テンプレート:Cite web


引用エラー: 「注釈」という名前のグループの <ref> タグがありますが、対応する <references group="注釈"/> タグが見つからない、または閉じる </ref> タグがありません