6 ms·

GPL is perfectly useful. It's just less useful for projects operating over the network. Are you writing a library that you want to be kept open when used in a

GPL is perfectly useful. It's just less useful for projects operating over the network. Are you writing a library that you want to be kept open when used in a project? GPL will do what you need. Are you writing an application where communicating over the network isn't a meaningful part of its operation? GPL will work fine. Are you writing a library or application where communicating over the network is a significant part of its operation? Yeah you probably want to use the AGPL instead. Even then, depending on where it is running, GPL might still be fine. JS on a client? GPL will be fine. JS on a server? You need AGPL. Really it comes down to: Does the user interact with this software with a network between them (i.e. user <--> ??? <--internet--> software)? If yes AGPL, if no GPL.

tpush 4y ago
Well, the point is that you can make almost every library a network service if your want to. Anytime a vendor sees a GPL3 library, all they have to do is make a network service out of it and the GPL3 license is powerless. So AGPL3 as the default for strong copyleft software seems reasonable.
- CuriousCosmic 4y ago
  Sure but for a lot of libraries that just doesn't make sense. Like I get that you can give any library an RPC and call it a day but with 90% of the libraries I work with on a daily basis, requiring that you call it over the network just adds unnecessary complexity, kills ergonomics of use, and adds latency. As an engineer I'm not going to use an RPC to do an FFT, populate a native UI, access some device, or manipulate a datastructure. Instead I'll just use a tool/library that does what I need while staying in the application's address space. The disconnect I think is that I work on a lot of embedded software and native applications. In the world I am in, the hoops needed to allow a library to bypass the GPL just mean that I'm not going to use that library and that I'll do everything in my power to keep leadership from using projects with that kind of pointless failure mode. The same goes for web apps though. If it's delivered to the client and executed by the client, it can just be GPL. They have a copy of the code and are running it. They already have to have access to a copy of the source. AGPL provides no additional protections here. AGPL has it's place and that place is server side software. If you are writing software that the user directly interacts with and that is running on hardware the user can physically touch, the AGPL provides you no added benefit. If that's not the case, you should certainly feel free to step the license up to AGPL but there's no reason to artificially complicate license compatibility when you already know that it wouldn't be feasible for a user/developer to use your software without complying with the GPL.
piaste 4y ago
> Are you writing a library that you want to be kept open when used in a project? GPL will do what you need. > Are you writing an application where communicating over the network isn't a meaningful part of its operation? GPL will work fine. This might be the case - although I agree with the sibling comment that a lot of libraries can be "artificially" turned into network services. But regardless, what's the downside of using the AGPL? It's GPL + some additional restrictions, and while those restrictions can sometimes be irrelevant, I can't think of how they could be harmful to a GPL project.
- GoblinSlayer 4y ago
  AGPL feels like overreach: the software runs on someone else's machine. AIU AGPL was problematic for proprietary versions of Mongo and Elastic, does it have proper free software purpose? SaaSS is inherently nonfree: you're not going to self-host AWS, google, dropbox or github.
gregmac 4y ago
> Are you writing a library that you want to be kept open when used in a project? GPL will do what you need. I'd argue it doesn't, really. GPL means it can only be used in software released under the GPL, or any network software (ie: web application) including proprietary. Specifically, a proprietary vendor can use and/or modify your GPL-licensed library on their server-side application and is not obligated under the terms of GPL to release any changes, so long as they never distribute the app. I'd argue using GPL for libraries is a good way to not get much usage. Every place I've ever worked has avoided GPL like the plague -- for startups it's a barrier to pivoting (eg: selling an on-prem version) and more importantly to being acquired, and any bigger companies have policy around it. On a personal level I also tend to avoid it unless it's either the only choice, or I want or already have released under the GPL. In general, given two library choices where one GPL and the other is MIT, I'm an order-of-magnitude more likely to pick the MIT one, even if it's lacking features compared to the GPL one, and even contribute the missing features. I suspect I'm not alone in this.
- CuriousCosmic 4y ago
  > Specifically, a proprietary vendor can use and/or modify your GPL-licensed library on their server-side application and is not obligated under the terms of GPL to release any changes, so long as they never distribute the app. Sure but if it doesn't make sense to use that service remotely, then just use the FOSS one instead. If the expected behavior is that the software you are writing will be running on a computer the user directly interacts with and can physically touch, it's probably fine to use the GPL. Web services and web libraries are a whole different ball game but I'm not going to use a GUI, signals analysis/transform, data structures, CUDA, hardware interface, or other common local library if I have to call it over a network. Doubly so if I now have to fight with an RPC endpoint instead of a DSL or library in my native language. And when I say GPL, there are a handful of different flavors. I generally think GPL+linker/classpath is a fine choice for most projects that are geared towards commercial use. I'd say LGPL is fine too and it is but there are some small differences between GPL+LE/CPE and LGPL. So for the sake of simplicity, "just default to GPL unless you have a good reason to increase or decrease the copyleft-ness".

tpush 4y ago

Well, the point is that you can make almost every library a network service if your want to. Anytime a vendor sees a GPL3 library, all they have to do is make a network service out of it and the GPL3 license is powerless. So AGPL3 as the default for strong copyleft software seems reasonable.

CuriousCosmic 4y ago
Sure but for a lot of libraries that just doesn't make sense. Like I get that you can give any library an RPC and call it a day but with 90% of the libraries I work with on a daily basis, requiring that you call it over the network just adds unnecessary complexity, kills ergonomics of use, and adds latency. As an engineer I'm not going to use an RPC to do an FFT, populate a native UI, access some device, or manipulate a datastructure. Instead I'll just use a tool/library that does what I need while staying in the application's address space. The disconnect I think is that I work on a lot of embedded software and native applications. In the world I am in, the hoops needed to allow a library to bypass the GPL just mean that I'm not going to use that library and that I'll do everything in my power to keep leadership from using projects with that kind of pointless failure mode. The same goes for web apps though. If it's delivered to the client and executed by the client, it can just be GPL. They have a copy of the code and are running it. They already have to have access to a copy of the source. AGPL provides no additional protections here. AGPL has it's place and that place is server side software. If you are writing software that the user directly interacts with and that is running on hardware the user can physically touch, the AGPL provides you no added benefit. If that's not the case, you should certainly feel free to step the license up to AGPL but there's no reason to artificially complicate license compatibility when you already know that it wouldn't be feasible for a user/developer to use your software without complying with the GPL.

piaste 4y ago

> Are you writing a library that you want to be kept open when used in a project? GPL will do what you need. > Are you writing an application where communicating over the network isn't a meaningful part of its operation? GPL will work fine. This might be the case - although I agree with the sibling comment that a lot of libraries can be "artificially" turned into network services. But regardless, what's the downside of using the AGPL? It's GPL + some additional restrictions, and while those restrictions can sometimes be irrelevant, I can't think of how they could be harmful to a GPL project.

GoblinSlayer 4y ago
AGPL feels like overreach: the software runs on someone else's machine. AIU AGPL was problematic for proprietary versions of Mongo and Elastic, does it have proper free software purpose? SaaSS is inherently nonfree: you're not going to self-host AWS, google, dropbox or github.

gregmac 4y ago

> Are you writing a library that you want to be kept open when used in a project? GPL will do what you need. I'd argue it doesn't, really. GPL means it can only be used in software released under the GPL, or any network software (ie: web application) including proprietary. Specifically, a proprietary vendor can use and/or modify your GPL-licensed library on their server-side application and is not obligated under the terms of GPL to release any changes, so long as they never distribute the app. I'd argue using GPL for libraries is a good way to not get much usage. Every place I've ever worked has avoided GPL like the plague -- for startups it's a barrier to pivoting (eg: selling an on-prem version) and more importantly to being acquired, and any bigger companies have policy around it. On a personal level I also tend to avoid it unless it's either the only choice, or I want or already have released under the GPL. In general, given two library choices where one GPL and the other is MIT, I'm an order-of-magnitude more likely to pick the MIT one, even if it's lacking features compared to the GPL one, and even contribute the missing features. I suspect I'm not alone in this.

CuriousCosmic 4y ago
> Specifically, a proprietary vendor can use and/or modify your GPL-licensed library on their server-side application and is not obligated under the terms of GPL to release any changes, so long as they never distribute the app. Sure but if it doesn't make sense to use that service remotely, then just use the FOSS one instead. If the expected behavior is that the software you are writing will be running on a computer the user directly interacts with and can physically touch, it's probably fine to use the GPL. Web services and web libraries are a whole different ball game but I'm not going to use a GUI, signals analysis/transform, data structures, CUDA, hardware interface, or other common local library if I have to call it over a network. Doubly so if I now have to fight with an RPC endpoint instead of a DSL or library in my native language. And when I say GPL, there are a handful of different flavors. I generally think GPL+linker/classpath is a fine choice for most projects that are geared towards commercial use. I'd say LGPL is fine too and it is but there are some small differences between GPL+LE/CPE and LGPL. So for the sake of simplicity, "just default to GPL unless you have a good reason to increase or decrease the copyleft-ness".