4 ms·

Is there a difference between static or dynamic linking for LGPL?

by yread 4y ago

TingPing 4y ago
Yes. The point of LGPL in concept is there is a clear boundary where you can modify and replace code. You can't replace a statically linked library.
- jcelerier 4y ago
  And yet https://www.gnu.org/licenses/gpl-faq.html#LGPLStaticVsDynamic https://www.gnu.org/licenses/gpl-faq.html#LGPLStaticVsDynami...
  - TingPing 4y ago
    I don't think that conflicts with what I said. You have to be able to replace the library and them shipping linkable objects does that. Most static releases do not do this.
    - jcelerier 4y ago
      The proprietary ones which use LGPL libraries do - it's uncommon as it's a bit more work for the proprietary dev but it happens
colejohnson66 4y ago
Yes. Because dynamic linking happens at runtime, the DLL/so file can be replaced by a downstream user. Static linking does not allow the user access to that "freedom", so the whole binary becomes "infected" and must be open sourced. By enforcing a "user replaceable" boundary, the users' freedoms/rights to modify the open-source library are unaffected. Side note: how does that fit in with cryptographic signatures? GPL v3 was written to combat "Tivoization" (open source, but can't replace the binary). Does the LGPL v3 disallow such things with DLL/so files (use hashes to prevent replacing the FOSS lib)?
- cmeacham98 4y ago
  Straight from the LGPLv3: "A suitable mechanism is one that (a) uses at run time a copy of the Library already present on the user's computer system, and (b) will operate properly with a modified version of the Library that is interface-compatible with the Linked Version."
OkayPhysicist 4y ago
The LGPL's boundary between your application and the licensed library requires that the end user have some way of substituting the LGPL library. So if your project is not at least source-available enough for the end user to recompile it with a modified version of the LGPL library, you're going to have a hard time meeting that requirement with static linking. More common is to just dynamically link to the LGPL library, which provides the substitution mechanism by its very nature.

Is there a difference between static or dynamic linking for LGPL?

by yread 4y ago

Is there a difference between static or dynamic linking for LGPL?

Yes. The point of LGPL in concept is there is a clear boundary where you can modify and replace code. You can't replace a statically linked library.

jcelerier 4y ago
And yet https://www.gnu.org/licenses/gpl-faq.html#LGPLStaticVsDynamic https://www.gnu.org/licenses/gpl-faq.html#LGPLStaticVsDynami...
- TingPing 4y ago
  I don't think that conflicts with what I said. You have to be able to replace the library and them shipping linkable objects does that. Most static releases do not do this.
  - jcelerier 4y ago
    The proprietary ones which use LGPL libraries do - it's uncommon as it's a bit more work for the proprietary dev but it happens

colejohnson66 4y ago

Yes. Because dynamic linking happens at runtime, the DLL/so file can be replaced by a downstream user. Static linking does not allow the user access to that "freedom", so the whole binary becomes "infected" and must be open sourced. By enforcing a "user replaceable" boundary, the users' freedoms/rights to modify the open-source library are unaffected. Side note: how does that fit in with cryptographic signatures? GPL v3 was written to combat "Tivoization" (open source, but can't replace the binary). Does the LGPL v3 disallow such things with DLL/so files (use hashes to prevent replacing the FOSS lib)?

cmeacham98 4y ago
Straight from the LGPLv3: "A suitable mechanism is one that (a) uses at run time a copy of the Library already present on the user's computer system, and (b) will operate properly with a modified version of the Library that is interface-compatible with the Linked Version."

OkayPhysicist 4y ago

The LGPL's boundary between your application and the licensed library requires that the end user have some way of substituting the LGPL library. So if your project is not at least source-available enough for the end user to recompile it with a modified version of the LGPL library, you're going to have a hard time meeting that requirement with static linking. More common is to just dynamically link to the LGPL library, which provides the substitution mechanism by its very nature.