8

Free Software Foundation は、EPL と GPL は互換性がないと考えています。彼らの推論を読んだところ、LGPL も同様に影響を受けるように思われます。IANAL さん、その読みが間違っている場合は訂正してください。現在、GPL で保護されたコードの著作権所有者が、互換性のないライブラリに対してコードをリンクすることを許可する例外を提供するためのガイドがあります。 EPL ライブラリに対してリンクされている)、GPL で保護されたプログラムを EPLおよび別の LGPL ライブラリに対してリンクする状況は不明のようです。

いくつかの質問に対する答えを知りたいです:

  1. EPL ライブラリと LGPL ライブラリの両方に対して GPL で保護された製品をリンクすることに対する制限は正確には何ですか? GPL の場合と同様に、LGPL 著作権所有者の明示的な許可がなければ許可されないのでしょうか、それとも許可されますか?
  2. EPL 著作権所有者が認めた例外で十分でしょうか? このような例外は、GPL と互換性のない独自の Qt Public License を使用して Qt ライブラリのライセンスを取得していた Trolltech (現在は Nokia の一部) によって安全であると見なされていました。KDE プロジェクトでは、そのライブラリは Qt にリンクされ、LGPL の下でリリースされますが、KDE ​​アプリは一般に GPL の下でリリースされます。FSF の異議は、「弱いコピーレフト」と「法の選択条項」によるものです。EPL ライセンス保有者が例外を認める場合、前者は異論の余地がないように見えますが、EPL 著作権保有者が認めたどのような例外が「の選択」を満たすでしょうか。法律条項」異議?
4

2 に答える 2

10

ここに画像の説明を入力

上の図は、ライセンス間の関係を示しています。包括的ではありませんが、矢印があれば互換性があります。

Eclipse の Web サイトには次のように記載されています。

EPL と GPL は、結果が (a) 「派生物」 (Eclipse は、米国著作権法におけるその用語の定義と一致して解釈する) または (b) 著作物のいずれかと見なされるような組み合わせでは互換性がありません。 GPLコードに「基づいて」、そのフレーズはGPLv2、GPLv3、またはGPL FAQで該当する場合に使用されます。さらに、これらのライセンスに基づくソース コードが両方とも同じソース コード モジュールであるシナリオでは、EPL コードと GPL コードを組み合わせることはできません。

Free Software Foundation の立場に基づいて、EPL と GPL のコードを、これらのライセンスの下で利用可能なコード間にリンクが存在するシナリオで結合することはできません。上記は GPL バージョン 2 と GPL バージョン 3 の両方に適用されます。

私の意見では、例外が作成されない限り、LGPL と EPL コードを組み合わせるべきではありません。実際、多くのソフトウェアが LGPL と EPL の下でデュアル ライセンスを取得しています。

于 2011-06-29T15:59:56.830 に答える
7

警告 Emptor: 私は弁護士ではありませんが、これらのライセンスをよく読みました。商業上の決定を行う場合は、弁護士に相談する必要があります。限目。そうしないと、重大な法的リスクにさらされることになります。

まず、具体的な質問にお答えください

質問: EPL ライブラリと LGPL ライブラリの両方に対して GPL で保護された製品をリンクすることに対する制限は正確には何ですか? GPL の場合と同様に、LGPL 著作権所有者の明示的な許可がなければ許可されないのでしょうか、それとも許可されますか?

答え: 分解が続きます。

  • LGPL 2 と 3 のコードを EPL 1.0 にリンクすることはおそらく問題ありません。
    • 参照: LGPL 2、セクション 5 :ライブラリのいかなる部分の派生物も含まないが、コンパイルまたはリンクすることによってライブラリと共に動作するように設計されたプログラムは、「ライブラリを使用する作品」と呼ばれます。
    • 参照: LGPL 3、セクション 4 :結合された作品に含まれるライブラリの部分の変更を事実上制限しない、選択した条件の下で結合された作品を伝達することができます...
  • LGPL 2 & 3 コードを GPL 2 & 3 コードにリンクすることはおそらく問題ありません。グラフを参照して、どの組み合わせが許可されているかを正確に理解するための @0A0D の回答をご覧ください。
  • GPL 2 & 3 コードを EPL 1.0 にリンクすることは絶対に許可されていません
    • 参照: @0A0D の回答を参照してください。
  • 著作権者の明示的な許可について:すべての著作権者から許可を得れば、おそらく何でもできます。これは法的にも物流的にも複雑であるため、ほぼ不可能と考えるべきです。
    • 例: (英雄的な努力で) Linux カーネルへのすべての貢献者から (お金で?) 許可を確保して、変更して非フリー (商用) としてリリースできるコードの BSD スタイルのライセンスを付与することができます。ソフトウェア。繰り返しますが、前述のとおり、可能ですが非現実的です。

質問: EPL 著作権所有者によって許可された例外で十分でしょうか? このような例外は、GPL と互換性のない独自の Qt Public License を使用して Qt ライブラリのライセンスを取得していた Trolltech (現在は Nokia の一部) によって安全であると見なされていました。KDE プロジェクトでは、そのライブラリは Qt にリンクされ、LGPL の下でリリースされますが、KDE ​​アプリは一般に GPL の下でリリースされます。FSF の異議は、「弱いコピーレフト」と「法の選択条項」によるものです -- 前者は、EPL ライセンス保有者が例外を認めた場合、異論の余地がないように見えますが、EPL 著作権保有者によって認められたどのような例外が「の選択」を満たすでしょうか。法律条項」異議?

答え: 分解が続きます。

  • EPL 著作権所有者が認めた例外で十分でしょうか?
    • 前述のように、これは可能ですが、EPL 1.0 コードの著作権所有者がそのような例外を認めることは非常に非現実的です。
  • Trolltech とマルチライセンスに関して、派生作品には通常、適用するライセンスを選択するオプションがあります。したがって、Trolltech/QPL/GPL の場合は、QPL のことは忘れて、GPL だけを使用してください。
  • KDE/LGPL に関しては、私は彼らのライセンス戦略に詳しくなく、コメントできません。しかし、確かに彼らは弁護士にそれを検討してもらいました。AFAIK: KDE はドイツで登録された非営利団体であり、これらの問題に関して無償の法的助言を受けている可能性があります。たとえそうでなくても、KDE ​​は十分古いので、準拠していなければ、著作権所有者は今までに確実に反対したでしょう。 詳しくはこちらをご覧ください。

最後に、Eclipse と OpenJDK の Java コードを結合しようとすると、同様の問題にも直面しています。

ライセンスを読んだところ、Eclipseが GPL 2 および 3 の非互換性ステートメントで派生物という用語を使用しているため、これらの作品の結合が明示的に許可されていることがわかりました。さらに、Classpath Exceptionは、このライブラリに対するリンクは派生物を作成しないと明確に述べています。

于 2013-06-08T17:30:37.947 に答える