3 ms·

The article mentions things like: - "All required code is compiled and/or linked into the executable, ..." - "No JIT means no dynamic loading of arbitrary

The article mentions things like: - "All required code is compiled and/or linked into the executable, ..." - "No JIT means no dynamic loading of arbitrary assemblies ..." - "... with everything compiled and linked into the app ..." This sounds very much like static linking, possibly with no option of dynamic linking/loading of code. Presumably this would have implications for those using LGPL-licensed .NET libraries, especially those who'd like to distributed closed-source applications AOT-compiled using this approach? Are there any commonly-used .NET libraries these days that are only LGPL-licensed? I haven't done .NET development in a decade, so I don't really know the current state of affairs.

yread 4y ago
Is there a difference between static or dynamic linking for LGPL?
- 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.
None4U 4y ago
I have used NativeAOT before, and it does not enforce static linking. "no dynamic loading of arbitrary assemblies" refers to .NET assemblies, not the native dynamic link libraries they are compiled (using NativeAOT) to

yread 4y ago

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

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.

None4U 4y ago

I have used NativeAOT before, and it does not enforce static linking. "no dynamic loading of arbitrary assemblies" refers to .NET assemblies, not the native dynamic link libraries they are compiled (using NativeAOT) to