3 ms·

The problem with GPL is, that it doesn't only require you to hand over any modifications to the GPL code - this would be easily to do, but to any code in a prod

by _ph_ 6y ago

The problem with GPL is, that it doesn't only require you to hand over any modifications to the GPL code - this would be easily to do, but to any code in a product built containing GPL code. And that is where the problems usually start. The reality is, not everyone agrees what the reality is and especially a company which takes licenses serious will be very careful to check, whether using GPL code is possible in a project. And no, we don't need another license, there are plenty of licenses available which resolve the issues. Be it the permissive licenses (MIT, BSD, ...) or GPL with linking exceptions.

arminiusreturns 6y ago
> 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 license family. I frequently see proprietary systems that have a notice list of the licenses they are using, including gplv2/3. Are they all in violation? I doubt it. GPL is my license of choice, (I have an almost completely gpl daily stack), so I'm not just being rhetorical, if there is something I'v missed I want to learn!
- 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,
dragonwriter 6y ago
> but to any code in a product built containing GPL code. No, to any code that is a part of a derivative work of GPL code; a product may often be an aggregate of code that is not a derivative work of GPL code and derivative-of-GPL code. What is legally a derivative work, OTOH, is not always simple and straightforward to determine, so to avoid conflict one might go the whole way out to the product boundary.
- _ph_ 6y ago
  With "containing" I didn't mean just delivered together as in shipping emacs together with your product, but making the GPL code part of it, especially linking with GPL code or even compiling together with the GPL code.
  - dragonwriter 6y ago
    Linking is an interesting case, because side notes from the FSF indicate that they think linking makes things a derivative works, but its far less clear if that is true under the law, especially for dynamic linking (API copyrightability, which is currently before the court, might have a lot to say about this).

by _ph_ 6y ago

arminiusreturns 6y ago

> 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 license family. I frequently see proprietary systems that have a notice list of the licenses they are using, including gplv2/3. Are they all in violation? I doubt it. GPL is my license of choice, (I have an almost completely gpl daily stack), so I'm not just being rhetorical, if there is something I'v missed I want to learn!

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,

dragonwriter 6y ago

> but to any code in a product built containing GPL code. No, to any code that is a part of a derivative work of GPL code; a product may often be an aggregate of code that is not a derivative work of GPL code and derivative-of-GPL code. What is legally a derivative work, OTOH, is not always simple and straightforward to determine, so to avoid conflict one might go the whole way out to the product boundary.

_ph_ 6y ago
With "containing" I didn't mean just delivered together as in shipping emacs together with your product, but making the GPL code part of it, especially linking with GPL code or even compiling together with the GPL code.
- dragonwriter 6y ago
  Linking is an interesting case, because side notes from the FSF indicate that they think linking makes things a derivative works, but its far less clear if that is true under the law, especially for dynamic linking (API copyrightability, which is currently before the court, might have a lot to say about this).