LGPL推移的依存関係を持つApache2.0ライブラリを使用した商用ソフトウェアの配布
サードパーティのlib（org.quartzscheduler）を使用する商用ソフトウェアプロジェクトがあります。これにはApache2.0ライセンスがあります。大丈夫だと思いましたが、推移的な依存関係を確認したところ、QuartzはLGPLの下で配布されているc3p0ライブラリを使用していることがわかりました。
私の理解では、LGPLはかなり「弱い」コピーレフトライセンスであるため、ライセンスに基づいてライブラリを直接修正していなければ、ソースコードを提供せずにlibを使用する商用ソフトウェアを配布できます。
私の理解は正しいですか？また、使用するライブラリの推移的な依存関係をどの程度気にする必要がありますか？どれくらい深く行く必要がありますか？
LGPLはGPLよりも「弱い」ですが、あなたが説明する方法ではありません。この違いは、LGPLのライブラリを変更したかどうかとは関係ありません。
これはあなたの直感を正しい軌道に乗せるのに役立つ非常に大まかな高レベルの説明です：GPLはあなたのプログラムがGPLされたコードを使用するならあなたのプログラム全体が無料（「4つの自由」によって定義される FSFはここで説明します ）。 LGPLでは、LGPLのコードを使用する場合、プログラムの残りの部分が無料でなくても、LGPLのコードは無料である必要があります。特に、これは、プログラムのすべてのユーザーが、プログラムの残りの部分を変更できない場合でも、プログラム内のLGPLライブラリを好きなように変更できる必要があることを意味します。
プログラムの残りの部分をクローズドソースのままにしておきたい場合、実際にはLGPLに準拠する最も簡単な方法は、通常、プログラムをLGPLのライブラリに動的にリンクすることです。静的よりも、エンドユーザーはコードを再コンパイルしたり再リンクしたりすることなく、ある.dllファイルを別の.dllファイルに簡単に交換できるためです。もう1つのあまり一般的ではないオプションは、プログラムに静的にリンクされたすべてのオブジェクトファイルを提供することですが、ソースコードは提供しないため、エンドユーザーはLGPLのライブラリを変更したい場合にリンクをやり直すことができます。詳細については、閲覧することを強くお勧めします FSFの公式FAQページGNUライセンス 。
推移的な依存関係に関しては、短いバージョンでは、これが心配な場合は、適切な弁護士がこの内容を確認する必要があります。依存関係の1つにあなたが知らなかったGPL依存関係がある場合、他の人と同じようにGPLに違反しているので、これは深刻な問題になる可能性があります。