GNU Lesser General Public License

この記事は検証可能な参考文献や出典が全く示されていないか、不十分です。 出典を追加して記事の信頼性向上にご協力ください。（このテンプレートの使い方） 出典検索?: "GNU Lesser General Public License" – ニュース · 書籍 · スカラー · CiNii · J-STAGE · NDL · dlib.jp · ジャパンサーチ · TWL (2021年10月)

GNU Lesser General Public License

GNU LGPLv3 ロゴ
作者	フリーソフトウェア財団
バージョン	3
公開元	フリーソフトウェア財団 (Free Software Foundation, Inc.[注釈 1]
リリース日	2007年6月29日
DFSGとの適合性	Yes
FSFの承認	Yes
OSIの承認	Yes
GPLとの適合性	Yes
コピーレフト	Yes (Weak copyleft; 弱いコピーレフト)
異種ライセンスコード からのリンク	Yes
テンプレートを表示

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

以前の名前から分かる通り、これは他のプログラムにリンクされることを前提としたライブラリのためのライセンスとして作成された。当ライセンスは、強いコピーレフト(strong copyleft)を持つライセンスであるGNU General Public LicenseすなわちGPLとBSDライセンス・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は主にソフトウェア・ライブラリに採用されるが、スタンドアローンなアプリケーションにも採用されるいくつかの例が存在した。もっとも有名な例は、かつてのMozillaとOpenOffice.orgである。

GPLとLGPLの主な相違点は、後者が、フリーソフトウェアかプロプライエタリソフトウェアかどうかに関わらず、非(L)GPLなプログラムにリンクされ得る（ライブラリの場合は「そのようなプログラムによって利用され得る」）というものである^[1][2]。この非(L)GPLプログラムはそれが二次的著作物(derivative work)ではない場合、任意の条項のもと頒布(英: distribution; 配布)してもよい。二次的著作物である場合は、LGPLv2.1第6節またはLGPLv3第4項の条項により、「顧客(カスタマー)自身の利用のための改変ならびにそのような改変をデバッグするためのリバースエンジニアリング」を許諾する必要がある^[3]。これは、GPLのように常に二次的著作物を同一の許諾条項に置くライセンスとは異なり、常に同一の許諾条件に置くとは限らないことを示している。LGPLなプログラムを利用する著作物が二次的著作物か否かは法的な問題である^{[注釈 2]}。ライブラリに動的リンク（すなわち共有ライブラリやダイナミックリンクライブラリなどによるリンク）する単体の実行ファイルは、法的に二次的著作物ではないと解釈される可能性がある^{[注釈 3]}。その場合、ライブラリにリンクするプログラムは、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で保護されたコードを直接再利用することや、また、プロプライエタリなソフトウェア製品に利用されないようにするコードのバージョンを作成したいと考える場合、有益となる。

以前の名前が"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][注釈 4]}。

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

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

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は次のことを保証する。この内容はGPLでも保証されている権利の一部である（このことからGPLよりも弱いコピーレフト性を持つ）。

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

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

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

• GNU General Public License (GPL)
• GNU Affero General Public License (AGPL)
• GPLリンク例外
• GNU Free Documentation License (GFDL)
• GNAT Modified General Public License (GMGPL)
• GNUプロジェクト
• フリーソフトウェアライセンス
• BSDライセンス
• パブリックドメインソフトウェア

• The GNU Lesser General Public License (原文)
  • GNU 劣等一般公衆利用許諾書 バージョン3 (八田真行による非公式日本語翻訳)
• The GNU Lesser General Public License, version 2.1 (原文)
  • GNU 劣等一般公衆利用許諾契約書 バージョン2.1 (八田真行による非公式日本語翻訳)
• Derivative Works - ライブラリがGPLである場合の二次的著作物の定義に関するローレンス・ローゼンの評論。