3 ms·

> proprietary usage > forbidden... from using The GPL doesn't apply when you are using Free Software, because the GPL is not an EULA. The only time the GPL b

by pdkl95 11y ago

> proprietary usage > forbidden... from using The GPL doesn't apply when you are using Free Software, because the GPL is not an EULA. The only time the GPL becomes relevant is when you want a licence to redistribute that software (or your derivative version). There are several options: you can choose to face the consequences of a copyright violation, you negotiate a specific licence with the authors of the software, or you can use the automatic licence granted by the GPL (provided you abide by the restrictions it imposes). For someone in operations, if you're just using the software and not making your own changes, there is nothing stopping you from using Free Software tools anywhere you want. If you want to incorporate Free source code into your own tool, the GPL only increases your options, as you can still negotiate with the authors, just like you would have to if you wanted to include other proprietary code. The only way the GPL could be seen as "punishing" anybody are the people that want to redistribute GPL code in their own product or tool without paying for it. If they don't like the price - recursively granting others the same freedom - then they are free to choose another vendor (or write their own version). > forbidden by legal Of course, if your legal department makes bad decisions because they do not understand the GPL, you may want to educate them (or refer them to the FSF)... or perhaps find a new legal department... or job.

ninkendo 11y ago
The semantics over what is considered a "distribution event" is not trivial, and it's largely seen as a "loophole" in the GPL that you can write a SaaS using GPL code and get away with it. (For instance, the AGPL closes this loophole.) Legal departments understand that using GPL code in proprietary services violates the "spirit" of the GPL, which is why they want to shy away from it. It's especially thorny because if say, a contractor logs into the server that's running your SaaS, and your SaaS is linked against a GPL library, technically that's a distribution event (because the contractor works for another company, and now you distributed it to him), and now your SaaS has to be licensed under the GPL too. Oops. When you consider all this, there's no wonder large companies just make blanket policies of no GPL, ever. And the GPLed works out there suffer, because those same large companies are happy to use permissively-licensed libraries, make fixes, and push those fixes upstream. But they can't do that with the GPL, because they don't want to touch it to begin with. It's ironically preventing the exact thing the GPL was meant to encourage.
- pdkl95 11y ago
  > SaaS Thankfully, the AGPL is working exactly as designed, because too many people want to try to fence off the commons. Again, if you don't want to pay the price for Free Software, find another vendor. The rest of us don't have any problem at all understanding what a "distribution event" is. The AGPL is only a problem if you base your business on limiting other people's freedom. Stop doing that. http://www.gnu.org/philosophy/who-does-that-server-really-serve.en.html http://www.gnu.org/philosophy/who-does-that-server-really-se...
  - ninkendo 11y ago
    I'm having a bit of trouble reading your response, it seems like you're driving at a few points simultaneously. (You only quoted one word out of my reply so I'm not sure exactly what you're trying to argue.) Are you defending AGPL and saying that proprietary SaaS software shouldn't use GPL code? Then I think you and I are 100% in agreement. My post was in response to the grandparent who seemed to be saying that the GPL is A-OK to use in proprietary web services because it's only relevant "when you want a licence to redistribute that software (or your derivative version)". I was explaining that that's more of a loophole in the GPL than it is "not relevant". I'm not basing a business on limiting others' freedom, I just want to write a dumb rails app for adding users to LDAP, or any other myriad of dumb reasons you'd want to make a dumb internal service. And I basically can't touch the GPL unless I can also convince our legal department to let me GPL the dumb tool and distribute the source code. Since things we distribute have a bit of brand identity to them, it would make my company look bad if the tool sucks, or it's not general-purpose enough to be useful outside my company, etc. So it's just not worth the hassle to go through all that for some dumb internal LDAP tool. So instead I stick with MIT/apache/etc permissively-licensed libraries in my dumb internal tools, find bugs in those libraries, and submit fixes upstream. Ironically this is the exact same thing that GPL proponents say would never happen if everyone used permissive licenses. I don't want to GPL my code and distribute it because I don't want anybody to see how bad it is, not because it's some "secret sauce" for my company. It's just a bunch of glue on existing libraries anyway (basically a variety of ruby gems.) The GPL is far too difficult for me to use in this case, so as a result I just don't touch it.

by pdkl95 11y ago

ninkendo 11y ago

The semantics over what is considered a "distribution event" is not trivial, and it's largely seen as a "loophole" in the GPL that you can write a SaaS using GPL code and get away with it. (For instance, the AGPL closes this loophole.) Legal departments understand that using GPL code in proprietary services violates the "spirit" of the GPL, which is why they want to shy away from it. It's especially thorny because if say, a contractor logs into the server that's running your SaaS, and your SaaS is linked against a GPL library, technically that's a distribution event (because the contractor works for another company, and now you distributed it to him), and now your SaaS has to be licensed under the GPL too. Oops. When you consider all this, there's no wonder large companies just make blanket policies of no GPL, ever. And the GPLed works out there suffer, because those same large companies are happy to use permissively-licensed libraries, make fixes, and push those fixes upstream. But they can't do that with the GPL, because they don't want to touch it to begin with. It's ironically preventing the exact thing the GPL was meant to encourage.

pdkl95 11y ago
> SaaS Thankfully, the AGPL is working exactly as designed, because too many people want to try to fence off the commons. Again, if you don't want to pay the price for Free Software, find another vendor. The rest of us don't have any problem at all understanding what a "distribution event" is. The AGPL is only a problem if you base your business on limiting other people's freedom. Stop doing that. http://www.gnu.org/philosophy/who-does-that-server-really-serve.en.html http://www.gnu.org/philosophy/who-does-that-server-really-se...
- ninkendo 11y ago
  I'm having a bit of trouble reading your response, it seems like you're driving at a few points simultaneously. (You only quoted one word out of my reply so I'm not sure exactly what you're trying to argue.) Are you defending AGPL and saying that proprietary SaaS software shouldn't use GPL code? Then I think you and I are 100% in agreement. My post was in response to the grandparent who seemed to be saying that the GPL is A-OK to use in proprietary web services because it's only relevant "when you want a licence to redistribute that software (or your derivative version)". I was explaining that that's more of a loophole in the GPL than it is "not relevant". I'm not basing a business on limiting others' freedom, I just want to write a dumb rails app for adding users to LDAP, or any other myriad of dumb reasons you'd want to make a dumb internal service. And I basically can't touch the GPL unless I can also convince our legal department to let me GPL the dumb tool and distribute the source code. Since things we distribute have a bit of brand identity to them, it would make my company look bad if the tool sucks, or it's not general-purpose enough to be useful outside my company, etc. So it's just not worth the hassle to go through all that for some dumb internal LDAP tool. So instead I stick with MIT/apache/etc permissively-licensed libraries in my dumb internal tools, find bugs in those libraries, and submit fixes upstream. Ironically this is the exact same thing that GPL proponents say would never happen if everyone used permissive licenses. I don't want to GPL my code and distribute it because I don't want anybody to see how bad it is, not because it's some "secret sauce" for my company. It's just a bunch of glue on existing libraries anyway (basically a variety of ruby gems.) The GPL is far too difficult for me to use in this case, so as a result I just don't touch it.