提供的目标文件是否满足LGPL relink子句?


10

SO的这个问题中,我读到:

专有源代码+ LGPL源代码

  • 静态链接:
    • 您必须将两个零件都作为LGPL发行。
    • 或提供一切使用户可以将应用程序与另一版本的LGPL源代码重新链接的功能。在这种情况下,其他要求与动态链接一样。

因此,就静态地将LGPL库链接到专有代码应用程序而言,听起来确实提供目标文件足以满足LGPL的要求。当可执行文件被静态链接时,提供目标文件可以使最终用户重新编译应用程序,从而链接到库的不同版本。

这是正确的吗?如果不正确,为什么呢?

Answers:


7

是的,你是完全正确的。为您的应用程序提供目标文件足以满足LGPL的要求,因为它允许用户选择使用其他版本来替换LGPL的库。

FSF甚至在其FAQ中明确表示

为了遵守LGPL(任何现有版本:v2,v2.1或v3):

(1)如果您静态链接到LGPL的库,则还必须以对象(不一定是源)格式提供应用程序,以便用户有机会修改库并重新链接应用程序。

(2)如果您动态链接到用户计算机上已经存在的LGPL库,则无需传达库的源代码。另一方面,如果您自己将可执行的LGPL库与应用程序一起传递(无论是静态链接还是动态链接),则还必须以LGPL提供的一种方式传递库的源代码。


1
那么,为什么Qt的“内部人员”和员工不断要求其他理由呢?Qt的LGPL是否经过修改?
IvanB '16

我不熟悉Qt的情况,但是从略过其许可页面的过程中,我看不到任何语言明确拒绝这种可能性。我认为他们只是为了推荐动态链接而忽略了它(对于大多数用户来说,这可能是更简单的解决方案)。我看到的最相关的措辞是:“在静态链接库的情况下,应用程序本身可能不再是“使用库的工作”,因此会受到LGPL的约束。建议动态链接或提供应用程序源代码归LGPL用户所有。”,这是完全合理的。
Ixrec

看起来Qt的某些模块仅在GPL下可用,而在LGPL下不可用,如果我没看错的话,那么如果他们确实提到了静态链接对象选项,那么他们也有可能必须坚持使用“除非使用X,Y或Z”和类似的无聊切向细节。
Ixrec

1
在一个完美的世界中,动态链接可能很棒,但是在这个世界中,当与Qt打交道时,动态链接就很困难。就像60兆字节的dll一样,其中许多部署工具没有引入,而依赖行者也没有检测到。在他们自己的LGPL常见问题解答中,我看到的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 '16

4
阅读他们的常见问题,似乎他们只是在虚假地宣称LGPL不允许专有应用程序静态链接到Qt,同时又非常暗示地暗示它。
IvanB '16
By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.