4 ms·

You're probably right, there is no LAGPL https://www.gnu.org/licenses/license-list.html#AGPL https://www.gnu.org/licenses/license-list.html#AGPL One could add

You're probably right, there is no LAGPL https://www.gnu.org/licenses/license-list.html#AGPL https://www.gnu.org/licenses/license-list.html#AGPL One could add that as an extra clause. It's not easy but one should always recursively check the licenses of every dependency. If one doesn't, one can't even enforce a ban on AGPL software because it might slip into a project deep inside the node_modules directory or the equivalent in that code base. A simple implementation could be looking for LICENSE files or files containing some keyword. If the file matches the standard licenses you know what they are. If they don't, they could be custom licenses and should be checked.

OkayPhysicist 3y ago
To be fair, it's not yet clear from the courts perspective what constitutes a derivative work in the world of software. There's a not-insignificant possibility that a future court decision will give a definition for "derivative work" in software that erases the difference between the LGPL and GPL. IMO, it's even somewhat likely. It's entirely unclear why the legal system would care whether something is statically linked or dynamically linked with regards to interpreting derivative works in software, so the question would likely boil down to simply "does linking a library make the application a non-fair use derivative work of the library"? If no, then there is no difference between the LGPL and GPL. If yes, the status quo remains.