オブジェクトファイルの提供はLGPL再リンク句を満たしますか?


9

SOに関するこの質問から、私はそれを読みました:

独自のソースコード+ LGPLソースコード

  • 静的にリンク:
    • どちらもLGPLとしてリリースする必要があります。
    • または、ユーザーがアプリケーションを別のバージョンのLGPLソースコードに再リンクできるようにするすべてを提供します。この場合、他の要件は動的にリンクされた場合と同じです。

したがって、オブジェクトファイルを提供するだけで、LGPLライブラリを独自のコードアプリケーションに静的にリンクするという点でLGPLを満たすのに十分であるように思えます。実行可能ファイルは静的にリンクされていますが、オブジェクトファイルを提供すると、エンドユーザーはアプリケーションを再コンパイルして、異なるバージョンのライブラリにリンクできます。

これは正しいですか、正しくない場合は、なぜですか?

回答:


6

はい、あなたは完全に正しいです。アプリケーションにオブジェクトファイルを提供するだけで、LGPLを満たすことができます。これにより、LGPLで作成されたライブラリを他のバージョンに置き換えることができます。

FSFはFAQでそのように明示的にさえ言っています

LGPL(現在のバージョン:v2、v2.1またはv3)に準拠するため:

(1)LGPL化されたライブラリーに静的にリンクする場合、ユーザーがライブラリーを変更してアプリケーションを再リンクできるように、アプリケーションをオブジェクト(必ずしもソースではない)形式提供する必要があります。

(2)ユーザーのコンピューターに既に存在するLGPL化されたライブラリーに対して動的にリンクする場合、ライブラリーのソースを伝える必要はありません。一方、アプリケーションと一緒に実行可能なLGPL化されたライブラリを静的または動的にリンクするかどうかを自分で伝える場合、LGPLが提供する方法の1つでライブラリのソースも伝える必要があります。


1
では、なぜQtは「インサイダー」であり、従業員は別の方法で主張し続けているのですか QtのLGPLは変更されていますか?
IvanB 2016年

私はQtの状況に精通していませんが、ライセンスページをざっと見ただけでは、この可能性を明確に否定する言語は見当たりません。ダイナミックリンクを推奨するために省略していると思います(ほとんどのユーザーにとって、これはおそらくより簡単なソリューションです)。「ライブラリの静的リンクの場合、アプリケーション自体が「ライブラリを使用する作業」ではなくなり、LGPLの対象となる可能性があります。動的にリンクするか、 LGPLの下でユーザーにアプリケーションのソースコードを提供します。」、これは完全に合理的です。
Ixrec 2016年

これらのページを正しく読んでいる場合、Qtの一部のモジュールはLGPLではなくGPLでのみ利用可能であるようにも見えます。そのため、オブジェクトとの静的リンクオプションに言及した場合、それらも取り組む必要がある可能性があります。 「X、Y、またはZを使用しない限り」および同様の退屈な接線の詳細。
Ixrec 2016年

1
完璧な世界では、動的リンクは素晴らしいかもしれませんが、この世界でQtを扱う場合、動的リンクは地獄です。60メガバイト以上のdllのように、その多くはデプロイメントツールが持ち込まず、Dependency Walkerが検出しません。彼ら自身のLGPL FAQに、私はThe LGPL allows you to keep the source code of your application private as long as it is “work that uses” the library. Dynamic linking is usually recommended here.強制的であることについては何も見ていません。
IvanB 2016年

4
彼らのFAQを読むと、彼らはLGPLがプロプライエタリなアプリケーションがQtに静的にリンクすることを許可しないが、それを暗示するのに非常に勤勉であると(偽)主張するのをためらっているようです。
IvanB 2016年
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.