2 ms·

I thought the purpose of the LGPL was that it could be used for libraries without tainting the stuff the library is linked against with viral GPL restrictions.

by hedora 3y ago

I thought the purpose of the LGPL was that it could be used for libraries without tainting the stuff the library is linked against with viral GPL restrictions. Concretely, using gcc with default settings will bring in glibc and compiler intrinsic code snippets which were both LGPL last time I checked. If I use GCC to compile and statically link closed source code that I have a redistribution without modification license for, then I can’t redistribute my binary without violating my license for the closed source code. Ouch! MUSL + clang it is, I guess. (I value my users’ right to own and operate computers even higher than their right to recompile code, so I’d rather not restrict my lgpl tainted binaries so they can only run in the cloud).

rescbr 3y ago
IIRC, GCC specifically uses GPL + runtime license exception to avoid this scenario
mort96 3y ago
glibc's LGPL is generally no problem because you honor that simply by dynamically linking against it. Normal desktop Linux distributions do have a "suitable shared library mechanism" as the LGPL calls it, so if your binary is dynamically linked against glibc, your users are free to link against the user's modified libc. The "Distribute object files to allow re-linking" thing only becomes relevant if you don't use a "suitable shared library mechanism" to dynamcially link against the LGPL-licensed library. However, if you do choose to statically link against glibc (which is highly discouraged, for technical reasons) then yeah, you have to give your users access to object files or some other mechanism to statically link against a different version of glibc than the one in the executables you ship. And yeah, this might potentially be incompatible with the licenses for certain proprietary libraries, which simply means that you can't statically link against those binaries and LGPL-licensed libraries at the same time. The stuff in GCC which gets includes into your binary (such as crt0.o, and whatever code it generates) is except from the GPL. I have no idea what you're talking about wrt restricting your users to only run your binaries in the cloud.
- hedora 3y ago
  If you sell a device with Linux and a proprietary blob on it, then you’re arguably doing the linking, not the user. On top of that, if you enable link time optimization, then you have to link at build. All of this would be allowed if you put the same device in a data center, and then had the user connect to it remotely.
  - mort96 3y ago
    Yeah, the embedded Linux context is messy. I don't know how the rules play out there (and I would be surprised if anyone truly knows). I thought we were talking about the general computing device use case. Link-time optimization isn't really relevant from what I understand; it's about optimizing across different object files when linking them together, it shouldn't have any impact on dynamic linking.

by hedora 3y ago

rescbr 3y ago

IIRC, GCC specifically uses GPL + runtime license exception to avoid this scenario

mort96 3y ago

glibc's LGPL is generally no problem because you honor that simply by dynamically linking against it. Normal desktop Linux distributions do have a "suitable shared library mechanism" as the LGPL calls it, so if your binary is dynamically linked against glibc, your users are free to link against the user's modified libc. The "Distribute object files to allow re-linking" thing only becomes relevant if you don't use a "suitable shared library mechanism" to dynamcially link against the LGPL-licensed library. However, if you do choose to statically link against glibc (which is highly discouraged, for technical reasons) then yeah, you have to give your users access to object files or some other mechanism to statically link against a different version of glibc than the one in the executables you ship. And yeah, this might potentially be incompatible with the licenses for certain proprietary libraries, which simply means that you can't statically link against those binaries and LGPL-licensed libraries at the same time. The stuff in GCC which gets includes into your binary (such as crt0.o, and whatever code it generates) is except from the GPL. I have no idea what you're talking about wrt restricting your users to only run your binaries in the cloud.

hedora 3y ago
If you sell a device with Linux and a proprietary blob on it, then you’re arguably doing the linking, not the user. On top of that, if you enable link time optimization, then you have to link at build. All of this would be allowed if you put the same device in a data center, and then had the user connect to it remotely.
- mort96 3y ago
  Yeah, the embedded Linux context is messy. I don't know how the rules play out there (and I would be surprised if anyone truly knows). I thought we were talking about the general computing device use case. Link-time optimization isn't really relevant from what I understand; it's about optimizing across different object files when linking them together, it shouldn't have any impact on dynamic linking.