Wikipedia

GNU Lesser General Public License

フリーソフトウェア財団が公開しているコピーレフト型のフリーソフトウェアライセンス

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

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
テンプレートを表示

概要

編集

以前の名前から分かる通り、これは他のプログラムにリンクされることを前提としたライブラリのためのライセンスとして作成された。当ライセンスは、強いコピーレフト(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との違い

編集

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で保護されたコードを直接再利用することや、また、プロプライエタリなソフトウェア製品に利用されないようにするコードのバージョンを作成したいと考える場合、有益となる。

ライブラリのライセンスに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の話題

編集

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

脚注

編集
[脚注の使い方]

注釈

編集
  1. ^ 法人の意味を含めている。
  2. ^ 二次的著作物の範囲の問題はライセンスに関わらずソフトウェア、そしてあらゆる著作物全てにおいて法的な問題であり、明確な判例はない。GPLについても同様であり、その見解についての詳細は、記事"GNU General Public License#リンクと派生物"に若干記載されている。
  3. ^ ライブラリに動的リンクされた実行ファイルがライブラリの二次的著作物か否かは法的な問題であり、LGPLとGPLで扱いに差はない。これは、LGPLやGPLが適用されたライブラリに動的リンクされた単体の実行ファイルが、LGPLにおいてライブラリの二次的著作物とみなされないなら、すなわちリバースエンジニアリングを許可する必要がないならば、GPLにおいてもライブラリの二次的著作物とみなされない、すなわち実行ファイルをGPLにする必要がないことを意味する。逆もまた然りである。
  4. ^ のち、FSFは、プロプライエタリ音声フォーマットに対しOgg+Vorbisへの置き換えを推奨する運動、PlayOggを開始している。 “PlayOgg!”. Free Software Foundation (2011年1月4日). 2011年4月3日閲覧。
  5. ^ generics
  6. ^ たとえばGNU/Linuxなどでは標準的なC言語のソースコードをコンパイルすると、LGPLであるglibcにリンクされる。このときコンパイルしたソースコードが独占的であったとしても、LGPLの条項を適用しなくてよい。[要出典]）
  7. ^ ライブラリAに静的リンクした場合に加えて、動的リンクしたプログラムが二次的著作物と見なされる場合も、リバースエンジニアリングを許可しなければならない。

出典

編集
  1. ^ a b c d Richard Stallman (2010年8月7日). “Why you shouldn't use the Lesser GPL for your next library”. Free Software Foundation. 2011年3月30日閲覧。
  2. ^ a b Richard Stallman、八田真行 (2006年11月16日). “あなたの次のライブラリにはライブラリGPLを適用するべきでない理由”. Free Software Foundation. 2011年3月29日閲覧。
  3. ^ “Q：GNU GPLとGNU LGPLの違いは何ですか？”. IPA. ossipedia.ipa.go.jp. 2011年8月5日閲覧。 “ほかのライセンスの適用が認められる条件とは、顧客が自分の用途に適応させるための改変を認めること、リバースエンジニアリングを認めることなどです。これらは、著作権法では認められているのに、商用ソフトウェアの利用許諾契約の多くで禁止されている項目です。”
  4. ^ “GNU Lesser General Public License, version 2.1”. Free Software Foundation. 2011年3月30日閲覧。
  5. ^ “Re: [open-source] [Fwd: [icecast-dev] Xiph.org announces Vorbis Beta 4 and the Xiph.org”. LWN.net（英語版） (2001年2月26日). 2011年3月29日閲覧。
  6. ^ “Preamble to the Gnu Lesser General Public License”. opensource.franz.com. 2011年3月30日閲覧。
  7. ^ 全文は次の通り。LGPLv2.1を対象に記述されているが、そのページの最上部に記載の通り、LGPLv3では条文の節番号が異なる点を除いて同じ内容が適用され得る。 David Turner (2004年). “The LGPL and Java”. Free Software Foundation. 2011年3月30日閲覧。

関連項目

編集
 
ポータル FLOSS

外部リンク

編集
「https://ja.wikipedia.org/w/index.php?title=GNU_Lesser_General_Public_License&oldid=97110648」から取得