4 ms·

> but to any code in a product built containing GPL code. Citation please. I don't think this is accurate, and is another common misunderstanding of the gpl li

• bartread 6y ago
  > Citation please. I don't think this is accurate, and is another common misunderstanding of the gpl license family. I believe you, but I also think (as stated in another comment) that if this is the case the GPL doesn't do a very good job of explaining itself. At the very least this creates friction when considering its adoption.
  • arminiusreturns 6y ago
    I think there is some truth there, but I think a lot more of the FUD on the copyleft licenses originates not from unclear licenses, but from a network effect where so many people repeat falsehoods, and to be honest, I wouldn't be surprised if some entities actively encouraged them.
  • toyg 6y ago
    > the GPL doesn't do a very good job of explaining itself The copious amount of side-notes [1][2][3] is likely to clarify most doubts, if one is willing to go through it. Obviously "contract law applied to software" is not a fun read though. [1] https://www.gnu.org/licenses/gpl-faq.html https://www.gnu.org/licenses/gpl-faq.html [2] https://www.gnu.org/licenses/gpl-howto.html https://www.gnu.org/licenses/gpl-howto.html [3] https://www.gnu.org/licenses/quick-guide-gplv3.html https://www.gnu.org/licenses/quick-guide-gplv3.html
• _ph_ 6y ago
  That is the problem, it entirely depends on how you use the GPL code and there is no definite legal precedence. If you use GPL code as part of your executable, the whole code used for building this executable falls under GPL. See for example the question, whether the non-GPL ZFS code can be linked against the GPL Linux kernel and the result distributed. See also all the GPL-only symbols the kernel exports. Another example is libreadline, which is put under GPL to force all applications using it to be licensed under GPL too. So there are clearly cases where using GPL code in your product can require the whole product be distributed under GPL. Of course, there are also cases, where this can be avoided. If I ship a product and I also ship emacs along with it, that doesn't influence my product. But if the product executable itself is derived from the emacs sources, it would.
• 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 ago
      Right. 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,