4 ms·

> 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 onl

> 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".

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".