3 ms·
Surprisingly hard to find a simple explanation from FSF, but here is a "proof by contradiction" explaining why should use GPL instead of the LGPL- https://www.
by topkai22 6y ago
Surprisingly hard to find a simple explanation from FSF, but here is a "proof by contradiction" explaining why should use GPL instead of the LGPL- https://www.gnu.org/licenses/why-not-lgpl.html https://www.gnu.org/licenses/why-not-lgpl.html
Basically, the LGPL exists because the GPL requires any binaries linking to GPLed code to inherit the GPL.
My understanding is that properitary programs can utilize / incorporate GPL binaries via interprocess communication (pipes, TCP, shared files, etc), but if they cannot do intra process communication without potentially violating the GPL.
So it depends on how your define "build" here :)
Regardless, because my role involves creating and distributing potentially proprietary software, I generally handle GPL projects with caution. I'll happily use Linux, but I don't look at the sources. If I see a GPL license on github, I'll generally move on. If I see something is AGPL licensed, I'll move on very quickly.
- bartread 6y ago> Basically, the LGPL exists because the GPL requires any binaries linking to GPLed code to inherit the GPL. This was my understanding too, but other comments in this discussion seem to imply that this might not be the case. If you could statically or dynamically link to GPL'd binaries without having to license your own code in the same way, then in the real-life examples I've seen we'd have had no concerns about either using GPL'd projects, or contributing modifications to the GPL'd projects back.
- _ph_ 6y agoRight. Contributing changes to the GPL'd software itself back isn't the issue. It is the intended "viral" nature of it, that also enforces the GPL onto all code linked to it. See for reference the issues with GPL-symbols in the Linux kernel, ZFS, or libreadline,