まず、私は弁護士ではありません。しかし、私は多くのライセンスを研究し、それらに関する問題を理解しています。
第二に、私はこれが古い質問であることを知っていますが、それでも混乱と懸念のポイントだと思います。気にしない場合は、そうすべきです。特に複数の貢献者が関与している場合、ライセンスを選択することは大したことです。
(L)GPLは、残念ながらC / C ++を念頭に置いて作成されました。「ソースコード」、「オブジェクトコード」、「動的リンク」、「静的リンク」、「コンパイラ」、および「オブジェクトコードインタープリター」について話します。したがって、これを同じコンパイル手法に従わない他の言語(Javaのバイトコード、Pythonのジャストインタイムコンパイル、Javascriptの解釈された性質など)に翻訳するには、いくつかの推測と仮定が必要です。法律について話している場合、つまり、2つの当事者が議論している最終的な裁判について考える場合、明確な区別がないことは悪いことです。
標準的なGPLライセンスのコードは、意図が非常に単純です。そのコードを使用する人は誰でも、配布または販売するときにすべてのユーザーにコードをリリースすることが期待されています。それは、リチャード・ストールマンが作成したかった、はっきりときれいにしたGPLウイルスです。
LGPLは元々、ウイルスではない「ライブラリ」を許可する試みでした。しかし、彼らはまだエンドユーザーが自分でライブラリを置き換えることができることを望んでいたため、「静的」リンクと「動的」リンクの区別-ユーザーは別の動的にリンクされたライブラリに交換できるので、必要はありませんGPLとしてライセンスされている。また、静的リンクではユーザーがGPLである必要がありました。このライセンスは実際には「ヘッダーファイル」について述べています。これはC / C ++では明確ですが、Java、Python、Javascriptなどの世界では明確ではありません。したがって、LGPLのもののL(「ライブラリ」)はせいぜい濁っています。
これが問題の核心になります。法律の世界では、不明確なことが悪いことです。GPLまたはLGPLコンポーネントのいずれかを使用して何かを構築しようとしている場合、法廷に着地した場合の将来の法的地位を確認したいと思います。しかし、今日の時点で、私は確かに判決を下していません。なぜなら、このようなフォーラムでの知的議論だけが、法的先例を確立する良い裁判例ではないからです。
クラスパス例外は非常に貴重です。ライセンス下のコードは(L)GPLであることが明確に記載されていますが、そのコードを使用するものは何でも好きなライセンスに従うことができます。ifs、ands、またはbutsはありません。コアコードを変更した場合(バグの修正など)、GPLの一部としてそれらの変更をリリースする必要があります。ただし、使用しても感染しません。
ビジネスの観点から、私はなぜ一部が10フィートの極でGPLコードに触れたくないのか理解しています。法的地位は不明確であり、法的先例がついに設定されると、ビジネスは10年先に突き刺される可能性があります。または、彼らは法的な先例を確立するために何年も闘っているかもしれません。とにかく、彼らはその戦いの費用を危険にさらしたくないだけです。Classpath Exception句を追加することにより、法的問題が排除され、(深刻な)潜在的な訴訟が回避されます。
したがって、私にとって、クラスパス例外はLGPLとは大きく異なります。GPLまたはLGPLのソースコードまたはライブラリの非GPL使用を可能にする明るい線を引くための法的にクリーンな方法です。