4 ms·

While it's true that the LGPL doesn't specifically require dynamic linking, it requires something that is effectively dynamic linking. The way you'd have to do

While it's true that the LGPL doesn't specifically require dynamic linking, it requires something that is effectively dynamic linking. The way you'd have to do static linking isn't something that is easy to set up in most build systems, and deprives you of the ability to do certain post-build steps (such as signing the build) or certain build options (LTO) without some pain.

jcelerier 5y ago
> The way you'd have to do static linking isn't something that is easy to set up in most build systems, it's trivial in CMake which is the most used buildsystem in languages with a linker, just set -DBUILD_SHARED_LIBS=0 on the command line > and deprives you of the ability to do certain post-build steps (such as signing the build) why would it ? I build my app as a set of static libs linked together in the end and there's no trouble signing it... and it does not make sense for people who will build their own custom version of your app to sign it. here's a guide inspired by instructions given by Cisco to rebuild one of their proprietary apps for instance on iOS: https://github.com/freedesktop/gstreamer/blob/master/README.static-linking#L109 https://github.com/freedesktop/gstreamer/blob/master/README....
- jcranmer 5y ago
  > it's trivial in CMake which is the most used buildsystem in languages with a linker, just set -DBUILD_SHARED_LIBS=0 on the command line Building or using static libraries isn't hard. Doing so in a way that doesn't violate the LGPL's replacement requirement is. The document you yourself linked says this about developing statically-linked libraries with the GPL: > If you statically link against an LGPLed library, you must also provide your application in an object (not necessarily source) format, so that a user has the opportunity to modify the library and relink the application. If you're distributing an object format, you need a .o that could be linked with the user's custom version of the LGPLed library. Building such a .o file cannot be done easily with tools, and that is what I'm referring to.
  - jcelerier 5y ago
    I don't understand, if you can build your app statically then you have the .o ; a static library libfoo.a is just an archive of .o files that pretty much any Unix system can extract
    - jcranmer 5y ago
      The final link line in a build system for an application is generally `cc -o app file1.o file2.o file3.o ... -llib1 -lib2 -llib3`. Turning that link line into one that produces an app.o that can be combined with liblgpllib.a to produce an equivalent app file is nontrivial. (And before you say just add all the .o files into a single .a file, no, that is not equivalent. Because Unix linking sucks).
      - jcelerier 5y ago
        ... how is that not equivalent ? ar is just tar with less features. At worse extract the .o's from the .a beforehand if that causes issues but I'd really like to know where this differs
  - dathinab 5y ago
    GPLs definition of "object" is not a .o file but "anything which is not source code".
    - im3w1l 5y ago
      So basically you could just tar up all the .o files and provide linking instructions?
      - jcelerier 5y ago
        Yes exactly !
anderskaseorg 5y ago
If the source code for your application is available and buildable, that satisfies the LGPL’s definition of “Corresponding Application Code”, regardless of how it’s linked. You don’t need the object code if you have the source code; you can replace the library by rebuilding the application. So this is only an inconvenience for proprietary closed-source applications. Making the library conveniently usable by closed-source applications is outside the stated objective in the blog post.
- dathinab 5y ago
  > available and buildable But what does buildable mean, no-one but you has access to your CI (which also might likely not be public). So do you need to provide another CI, a make-file you maintain additionally, etc.? Or is it good enough so that someone could run "the right CLI commands to build and link the project".
  - jcelerier 5y ago
    Entirely outside of the licensing debate, if your project only builds on a specific CI that's a huge engineering red flag I'd say
  - anderskaseorg 5y ago
    You can read this in the license: > The “Corresponding Source” for a work in object code form means all the source code needed to generate, install, and (for an executable work) run the object code and to modify the work, including scripts to control those activities. A good open-source (or even source-available) project will include all the necessary build scripts and instructions needed for rebuilding it anyway, and it will be portable enough that this process isn’t tied down to a non-public CI environment. If you’re asking exactly how much of this you can legally get away with omitting from a project using an LGPL library, then (a) you’re clearly not interested in providing a good open-source project, and (b) you should probably consult a lawyer rather than looking for free armchair legal advice from the community that you’re trying to avoid contributing to.
  - lmm 5y ago
dathinab 5y ago
If you provide intermediate binary build artifacts i.e. C object files, there it no problem with LTO or signing builds. I.e. nothing in the LGPL requires you to sign the changed/re-linked binary as far as I known. Similar nothing requires you to sign the provided intermediate artifacts. Still only relay viable for C, and maybe C++ if no/few templates where used around the interface. (Or scripting languages bundles with a runtime into a binary.)

jcelerier 5y ago

> The way you'd have to do static linking isn't something that is easy to set up in most build systems, it's trivial in CMake which is the most used buildsystem in languages with a linker, just set -DBUILD_SHARED_LIBS=0 on the command line > and deprives you of the ability to do certain post-build steps (such as signing the build) why would it ? I build my app as a set of static libs linked together in the end and there's no trouble signing it... and it does not make sense for people who will build their own custom version of your app to sign it. here's a guide inspired by instructions given by Cisco to rebuild one of their proprietary apps for instance on iOS: https://github.com/freedesktop/gstreamer/blob/master/README.static-linking#L109 https://github.com/freedesktop/gstreamer/blob/master/README....

jcranmer 5y ago
> it's trivial in CMake which is the most used buildsystem in languages with a linker, just set -DBUILD_SHARED_LIBS=0 on the command line Building or using static libraries isn't hard. Doing so in a way that doesn't violate the LGPL's replacement requirement is. The document you yourself linked says this about developing statically-linked libraries with the GPL: > If you statically link against an LGPLed library, you must also provide your application in an object (not necessarily source) format, so that a user has the opportunity to modify the library and relink the application. If you're distributing an object format, you need a .o that could be linked with the user's custom version of the LGPLed library. Building such a .o file cannot be done easily with tools, and that is what I'm referring to.
- jcelerier 5y ago
  I don't understand, if you can build your app statically then you have the .o ; a static library libfoo.a is just an archive of .o files that pretty much any Unix system can extract
  - jcranmer 5y ago
    The final link line in a build system for an application is generally `cc -o app file1.o file2.o file3.o ... -llib1 -lib2 -llib3`. Turning that link line into one that produces an app.o that can be combined with liblgpllib.a to produce an equivalent app file is nontrivial. (And before you say just add all the .o files into a single .a file, no, that is not equivalent. Because Unix linking sucks).
    - jcelerier 5y ago
      ... how is that not equivalent ? ar is just tar with less features. At worse extract the .o's from the .a beforehand if that causes issues but I'd really like to know where this differs
- dathinab 5y ago
  GPLs definition of "object" is not a .o file but "anything which is not source code".
  - im3w1l 5y ago
    So basically you could just tar up all the .o files and provide linking instructions?
    - jcelerier 5y ago
      Yes exactly !

anderskaseorg 5y ago

If the source code for your application is available and buildable, that satisfies the LGPL’s definition of “Corresponding Application Code”, regardless of how it’s linked. You don’t need the object code if you have the source code; you can replace the library by rebuilding the application. So this is only an inconvenience for proprietary closed-source applications. Making the library conveniently usable by closed-source applications is outside the stated objective in the blog post.

dathinab 5y ago
> available and buildable But what does buildable mean, no-one but you has access to your CI (which also might likely not be public). So do you need to provide another CI, a make-file you maintain additionally, etc.? Or is it good enough so that someone could run "the right CLI commands to build and link the project".
- jcelerier 5y ago
  Entirely outside of the licensing debate, if your project only builds on a specific CI that's a huge engineering red flag I'd say
- anderskaseorg 5y ago
  You can read this in the license: > The “Corresponding Source” for a work in object code form means all the source code needed to generate, install, and (for an executable work) run the object code and to modify the work, including scripts to control those activities. A good open-source (or even source-available) project will include all the necessary build scripts and instructions needed for rebuilding it anyway, and it will be portable enough that this process isn’t tied down to a non-public CI environment. If you’re asking exactly how much of this you can legally get away with omitting from a project using an LGPL library, then (a) you’re clearly not interested in providing a good open-source project, and (b) you should probably consult a lawyer rather than looking for free armchair legal advice from the community that you’re trying to avoid contributing to.
- lmm 5y ago

dathinab 5y ago

If you provide intermediate binary build artifacts i.e. C object files, there it no problem with LTO or signing builds. I.e. nothing in the LGPL requires you to sign the changed/re-linked binary as far as I known. Similar nothing requires you to sign the provided intermediate artifacts. Still only relay viable for C, and maybe C++ if no/few templates where used around the interface. (Or scripting languages bundles with a runtime into a binary.)