当社は、LGPLが適用されるライブラリを利用してシステムを開発しています。この場合、ライブラリにリンクするプログラムにはソースコード開示義務が及ばないと聞きましたが、本当でしょうか。
LGPLは、ユーザに対しソースコードを提供しなければならない義務（ソースコード開示義務）が、GPLに比べて緩和されています。ただし、いかなる範囲でソースコード開示義務が及ぶのかは、慎重に検討する必要があります。
１ LGPLとは
LGPL（Lesser GNU GENERAL PUBLIC LICENSE[1]）は、GPL（GNU GENERAL PUBLIC LICENSE）の派生ライセンスであり、そのライセンスが適用されるプログラム（主にライブラリ）が他のプログラムにリンクされることが想定されています。
そもそも、GPLには、OSS（オープン・ソース・ソフトウェア※1）を製品に組み込むなどして、実行可能ファイル等のオブジェクトコードをユーザに配布（譲渡、貸与等）する場合、通常、そのユーザ（受領者）に対し、そのソフトウェアのソースコードを提供しなければならないという条件が課せられます（ソースコード開示義務※2）。
また、そのOSSとリンクするソフトウェアがある場合、そのソフトウェアにもGPLが適用され、ソースコード開示義務が及びます（この点を揶揄し、「GPL汚染」などと言われることもあります。）。
※1 OSSのより詳細な解説については、以下の記事をご覧ください。
OSSライセンスの基礎知識
※2 ソースコード開示義務のより詳細な解説については、以下の記事をご覧ください。
GPL系のOSSライセンスとソースコード開示義務
上記のとおり、GPLが適用されるOSSは、ソースコード開示義務がそのリンク先のプログラムにも及ぶことから、プロプライエタリなソフトウェア（入手・使用・改変・複製等の権利を制限するようなもの。OSSと対極的な位置づけにある。）とリンクさせることができないという問題がありました。
この問題に対応するように生まれたのがLGPLといえます。
LGPLにおいては、一定の条件を満たすことにより、ライブラリとリンクするプロプライエタリなソフトウェアにソースコード開示義務が及ばず、両者のライセンスを両立させることができるとされています。
２ LGPLにおけるオブジェクトコード配布の条件
LGPL（主に、バージョン2.1（v2.1）又はバージョン3（v3）が採用されます。）においては、LGPLが適用されるライブラリ（以下「ライブラリ」といいます。）及びこれとリンクするソフトウェア（以下「アプリ」といいます。）について、以下の条件を満たすことにより、実行可能ファイル等のオブジェクトコードにより配布（譲渡、貸与）することができるとされています（LGPLv2.1第6項第1パラグラフ、LGPLv3第4項第1パラグラフ）。
【条件】
・ライブラリを利用（リンク等）するプログラム（アプリ）についてユーザによる改変を可能とし、そのデバッグのためのリバースエンジニアリングを許可する（※3）
・LGPLが適用されるライブラリの使用事実、そのライセンス条件、著作権表示を示す
・ライブラリ部分のソースコードを開示する[2]
・【ライブラリとアプリがいわゆる静的リンクにより結合されている（ライブラリとアプリがリンクされて実行可能ファイルとなっている）場合】
アプリのソースコードあるいはオブジェクトコードのいずれかを開示する（どちらか一方でよい）
・【ライブラリとアプリがいわゆる動的リンクにより結合されている（アプリ実行時にユーザのコンピュータ上に存在するライブラリのコピーを利用する[3]）場合】
ソースコードもオブジェクトコードも開示する必要がない
※3：改変・リバースエンジニアリングの許可範囲について
上記改変・リバースエンジニアリングを許可すべき範囲については解釈が分かれるところです。
LGPLv2.1においては、ライブラリを利用するプログラムの改変を許可し、またそのような改変をデバッグするためのリバースエンジニアリングを許可しなければならないとあるため（第6項柱書）、アプリ部分のリバースエンジニアリングまで許可する必要があると考えられます。
他方で、LGPLv3においては、ライブラリ部分の改変を事実上禁止したり、そのような改変をデバッグするためのリバースエンジニアリングを禁止したりしないことが規定されており（第4項柱書）、ライブラリとリンクするアプリ部分のリバースエンジニアリングまで許可する必要はないとも考えられます。ただし、アプリのリバースエンジニアリングを許可しなければ、技術的にライブラリの改変又はそのデバッグが困難になるというのであれば、v3においてもやはり、アプリ部分まで含めて改変・リバースエンジニアリングを許可する必要があるという解釈に近づきます[4]。
以上より、アプリがライブラリと動的リンクする場合には、アプリ部分についてソースコード（及びオブジェクトコードすら）を開示する必要がないということになります。ただし、上記のとおり、リバースエンジニアリングの許可条項が存在するため、アプリとライブラリを結合させたソフトウェアを販売する際、エンドユーザとのソフトウェアライセンス契約（いわゆる「EULA」）において、当該ソフトウェアについてリバースエンジニアリング禁止条項等を設けないように留意する必要があります。
３ GPLとLGPLの両立性
GPLは、OSSの配布にあたり、GPLに規定している以上に追加的に制限を課してはならないとされています（GPLバージョン2（v2）第6項、GPLバージョン3（v3）第7項第4パラグラフ、第10項第3パラグラフ）。
条件が緩和されているライセンスであれば、GPLと両立しますので、LGPLv2.1とGPLv2、LGPLv3とGPLv3は両立性がありますが、GPLv2とv3とは非両立、GPLv2とLGPLv3とは非両立というように、互いのバージョンが異なる場合は、各ライセンス条件が非両立であると考えられていますので[5]、GPLとLGPLを取り扱う上では、バージョン情報にも留意してシステムを開発する必要があります。
2024年9月9日
[1] 以前は、主に他のプログラムにリンクされるライブラリに適用することを想定したライセンスであるとして、GNU Library General Public Licenseとされていました。
[2] ただし、ライブラリがプログラムと動的リンクする場合であって、そのライブラリがユーザのコンピュータ内に既に存在する場合（ライブラリとアプリを合わせて提供するのでない場合）には、重ねてライブラリのソースコードを提供する必要はないと考えられます。
https://www.gnu.org/licenses/gpl-faq.ja.html#LGPLv3ContributorVersion
[3] LGPLにおいては、本文中に述べた条件に加えて、アプリとインターフェースに互換性のあるライブラリの修正版とも適切に動作するようになっていることが求められています（LGPLv2.1第6項第1パラグラフb）(2)、v3第4項第1パラグラフd)1)(b)。
[4] 一般財団法人ソフトウェア情報センター「IoT 時代におけるOSS の利用と法的諸問題Q&A集」159～164頁ご参照。
https://softic.or.jp/ossqa/index.htm
[5] https://www.gnu.org/licenses/license-list.html.en#GPLCompatibleLicenses
