3 ms·

Not true at all. The LGPL does not specify anything about mode of linking or anything like that. What the LGPL requires is that the end user be able to take th

Not true at all. The LGPL does not specify anything about mode of linking or anything like that. What the LGPL requires is that the end user be able to take the source code for the LGPL part, modify it, recompile it, and then replace the functionality in your binary provided by that part with their new part. Obviously with dynamic linking this is almist trivial, the end user replaces the so or DLL and done. With normal static linking, it's only a bit harder. If you ship alongside your binary a bundle of eg .o files and a script that links them together with a .a for the LGPL part for example, this is also compliant without revealing the source code to your non-lgpl part.

Wowfunhappy 2y ago
> If you ship alongside your binary a bundle of eg .o files and a script that links them together with a .a for the LGPL part for example, this is also compliant without revealing the source code to your non-lgpl part. This is super clever, I love it! Does any software actually do this?
- jcelerier 2y ago
  Yes. For instance some Cisco app on iOS that uses gstreamer (LGPL) does exactly this.
  - jimbobthrowawy 2y ago
    Do you mean iOS the iphone operating system, or cisco IOS the router operating system?
    - jcelerier 2y ago
      the iPhone operating system: https://www.cisco.com/c/dam/en/us/td/docs/voice_ip_comm/jabber/iOS/12_6/Cisco-Jabber-for-iPhone-and-iPad-12-6_Licensing_Information.pdf https://www.cisco.com/c/dam/en/us/td/docs/voice_ip_comm/jabb...
bla3 2y ago
The linked post does mention that: > or distribute object files for recompilation
leni536 2y ago
> If you ship alongside your binary a bundle of eg .o files and a script that links them together with a .a for the LGPL part for example, this is also compliant without revealing the source code to your non-lgpl part. Do you need to ship it alongside or produce it on request or link to where they can fetch it? It's not like you need to ship source code alongside either for GPL binaries.
alok-g 2y ago
Cool! Does this also mean that one could put most of the closed source part into a DLL, make a shell executable that is open source and statically link LGPL code into the latter? This then would allow modifications to the LGPL code to be put in just by having the closed source DLL.
- singpolyma3 2y ago
  I don't see why not. So long as the LGPL part can be modified and replaced, you're good. I am not a lawyer.
- saagarjha 2y ago
  I mean, if you're willing to do that why not just dynamically link?
  - alok-g 2y ago
    The OP article is saying that static linking leads to size reduction. That's why asking.
    - saagarjha 2y ago
      You’re not getting a size reduction if you maintain a library boundary, though. What you’re doing is isomorphic to dynamically linking except the app code is in the library and the library code is in the main binary.
      - alok-g 2y ago
        Ok. I understood. Thanks for explaining.
cesarb 2y ago
> If you ship alongside your binary a bundle of eg .o files You might even be able to use partial linking (ld -r) to ship a single .o file instead of a bunch of them.

Wowfunhappy 2y ago

> If you ship alongside your binary a bundle of eg .o files and a script that links them together with a .a for the LGPL part for example, this is also compliant without revealing the source code to your non-lgpl part. This is super clever, I love it! Does any software actually do this?

jcelerier 2y ago
Yes. For instance some Cisco app on iOS that uses gstreamer (LGPL) does exactly this.
- jimbobthrowawy 2y ago
  Do you mean iOS the iphone operating system, or cisco IOS the router operating system?
  - jcelerier 2y ago
    the iPhone operating system: https://www.cisco.com/c/dam/en/us/td/docs/voice_ip_comm/jabber/iOS/12_6/Cisco-Jabber-for-iPhone-and-iPad-12-6_Licensing_Information.pdf https://www.cisco.com/c/dam/en/us/td/docs/voice_ip_comm/jabb...

bla3 2y ago

The linked post does mention that: > or distribute object files for recompilation

leni536 2y ago

> If you ship alongside your binary a bundle of eg .o files and a script that links them together with a .a for the LGPL part for example, this is also compliant without revealing the source code to your non-lgpl part. Do you need to ship it alongside or produce it on request or link to where they can fetch it? It's not like you need to ship source code alongside either for GPL binaries.

alok-g 2y ago

Cool! Does this also mean that one could put most of the closed source part into a DLL, make a shell executable that is open source and statically link LGPL code into the latter? This then would allow modifications to the LGPL code to be put in just by having the closed source DLL.

singpolyma3 2y ago
I don't see why not. So long as the LGPL part can be modified and replaced, you're good. I am not a lawyer.
saagarjha 2y ago
I mean, if you're willing to do that why not just dynamically link?
- alok-g 2y ago
  The OP article is saying that static linking leads to size reduction. That's why asking.
  - saagarjha 2y ago
    You’re not getting a size reduction if you maintain a library boundary, though. What you’re doing is isomorphic to dynamically linking except the app code is in the library and the library code is in the main binary.
    - alok-g 2y ago
      Ok. I understood. Thanks for explaining.

cesarb 2y ago

> If you ship alongside your binary a bundle of eg .o files You might even be able to use partial linking (ld -r) to ship a single .o file instead of a bunch of them.