Huh? The whole point of the LGPL is to say, "you can use the LGPL'd code in your closed-source product, but the user must be able to replace the LGPL part of your product with their own version". The way to achieve that is to either use some kind of dynamic linking where the user can provide their own .so/.dll/.dylib of the LGPL'd library, or to provide the object files so that the user can statically re-link the application with their own version of the LGPL'd library.
This is different from GPL, since you can't use GPL'd code in your closed-source product at all, not even if you let the user replace the GPL'd portion with their own version.
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).
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.
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.
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.
The purpose of /which/ LGPL? And that's the thing. After GPL demonstrated that it had teeth and got some case law underneath it, the "family" of derivatives exploded, each one of them identifying as "open source" but each with their own additions, removals, modifications or other opinions on what "freedoms" they convey (mostly removals).
There are those of us out here who believe that the core purpose of all of these licenses were defeated a long time ago when all of this legal swizzling first began. I personally hate GPLv3, AGPL, LGPLv3, etc. with a fiery burning passion; thank god we were able to see some transformative projects emerge under actually free licenses before everything got ruined.
Either 2.1 or 3.0 I guess, the difference between the versions isn't that relevant to hedora's question.
The GPL exists to protect users against companies which develop proprietary software. If you prioritize the freedom of companies to restrict users over the freedom of those users, it makes sense that you'd dislike the GPL style licenses.
> I personally hate GPLv3, AGPL, LGPLv3, etc. with a fiery burning passion; thank god we were able to see some transformative projects emerge under actually free licenses before everything got ruined.
Why do you hate them so much? Is it strictly as a developer, or as a user?
As a developer I've certainly felt constrained and annoyed by them at times, and I'm very glad there are alternative open source licenses available, but as a user I can't imagine a scenario where you would hate them. After all, the freedom they guarantee is to the user, not the developer.
Even as a developer though, the family has it's place. I don't think Linux would be a thing had it had a more "permissive" license. That GPL is what forces the big corps to contribute their improvements back. If not for the GPL, I think it would be in a position similar to that of BSD, and the majority of users would have no choice but to use a proprietary OS
Notice the lack of "GPL" in that list, and I'm partially in agreement.
The GPL is amazing and wonderful, but the various "attachments" of the GPL are more weaponized (and to the detriment of users!) than the GPL ever was.
I'm glad the kernel stuck with GPLv2, and I wish other things had, too. A GPLv3 Linux Kernel would likely have helped a BSD tremendously, though but I think having everyone work on the same kernel without reservations has been an unmitigated good.
It's different enough that Apple thinks it's only safe for them to ship GPLv2 software on MacOS devices, not GPLv3.
This might have something to do with the way they sign shipped versions and use TPM security to verify what's run, even though you can manually disable some of this if you want.
So all GPL the software shipped on MacOS devices is stuck at the last version which used GPLv2, and they rewrote Samba which they had previously shipped, whose last GPLv2 version is too out of date to keep using.
This is different from GPL, since you can't use GPL'd code in your closed-source product at all, not even if you let the user replace the GPL'd portion with their own version.
What purpose of the LGPL is defeated?