3 ms·
> which means you can’t really static link to it from a closed source program Incorrect. https://www.gnu.org/licenses/gpl-faq.html#LGPLStaticVsDynamic https:/
by michaelsbradley 3y ago
> which means you can’t really static link to it from a closed source program
Incorrect.
https://www.gnu.org/licenses/gpl-faq.html#LGPLStaticVsDynamic https://www.gnu.org/licenses/gpl-faq.html#LGPLStaticVsDynami...
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.
- superq 3y agoThat might be very challenging, depending on which language you are using.
- dralley 3y agoWhich is why I personally dislike the LGPL. It's a hacky license that has too many asterisks. GPL and MPLv2 are straightforwards by comparison.
- tom_ 3y ago"Did you just tell me to go fuck myself?" "I believe I did, Bob." I'm being more than a bit mean here, in my attempt to be slightly amusing, because there's actually an obvious workaround: dynamically link with the LGPL library, like people usually do, and then it's nice and easy. The sort of systems where this would be difficult are the sort of systems where actually distributing a GPL program is just going to be annoying anyway, and you're probably better off not even trying. But it is actually an interesting idea! I assume for the average program you'd be including more of your symbol information than you might like, though, as object files have to find their external symbols somehow! (I imagine LTCG will add a lot of additional information as well. All this would add up to a lot of useful info that would assist in the sort of reverse-engineering effort that proprietary software vendors would like to make more tedious, rather than less so.) But, if you really wanted to do it, and didn't mind putting a bit of effort in, you could probably do something. An enormous non-LTCG translation unit containing all of the code, probably.