提供的目标文件是否满足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.