3 ms·
It's interesting to see how this is playing out. From a business's perspective, there are can absolutely be legitimate concerns to taking certain kinds of depe
by mumblemumble 6y ago
It's interesting to see how this is playing out.
From a business's perspective, there are can absolutely be legitimate concerns to taking certain kinds of dependencies on GPL software. But the ones that seem most legitimate to me concern core library dependencies. I have a really hard time seeing how one would be comfortable, as so many businesses are, with building their entire tech stack on top of OpenJDK, but then balk at a database server that isn't even running in the same process space as the rest of your code.
Is there any legal grounding there, or is it just that we're all comfortable with Java, whereas a new database is a new thing, and we're naturally more fearful about new things?
- jabl 6y agoOpenJDK isn't "pure" GPL, it's GPL with the classpath exception making it more like LGPL.
- vvillena 6y agoAFAIK the classpath exception is intended to make the ecosystem work in a similar way to how GPL system libraries interface with non-GPL C code. Please correct me if I'm wrong.
- jabl 6y agoWell, presumably you mean LGPL system libraries like glibc etc., but yes, I understand that is roughly the idea. I think they came up with GPL + classpath exception instead of adopting LGPL because LGPL has all this language about static vs. dynamic linking etc. that is rooted in the C world and not how Java does things.
- mumblemumble 6y agoMy company's legal team is fine with GPL + classpath exception, but skittish about LGPL. It had never really occurred to me that that might be the reason why. Perhaps the problem is that the LGPL's C-centric language means that trying to use it as a general-purpose library for any platform, including ones that don't work like C, puts it in murkier legal waters.