3 ms·

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

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

by tpush 4y ago

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.