fhd
LGPL Licensing
We're running into a bit of a licensing issue which I'm hoping could be solved. Most clojure dependencies are distributed under EPL rather LGPL. One of the finer points of EPL is you can create closed-source applications that use your library. The LGPL requires you distribute your library SxS for dynamic relinking should someone want to swap versions.
On some level this doesn't really matter for clostache itself - clostache is Clojure only. Jars let you do the above pretty easily. If you just use clostache server-side without giving users software binaries, there aren't any disclosure requirements to your end users.
The rough part is cljstache - the clojurescript fork of clostache. Given the way clojurescript compiles code (under advanced compilation), making a library dynamically linkable is extremely difficult. It's not really a design goal for most javascript.
I know this might be a long shot, but would this project consider re-licensing it's code under the EPL? There's only about 15 contributors so it might be doable. The license is extremely similar but allows for unmodified closed-source use.
I hadn't anticipated that problem to be honest, good point. I have nothing against it, really. It was more of an old habit of mine to use LGPL for libraries. I happen to talk to a software lawyer today, so I'll ask him about this and get back to you.
So, according to my lawyer, it's fine. It doesn't have to be technically linked, it's more the spirit of the license that matters in case someone claims a violation. So including a JS library without modifying it in software that's under a non-GPL compatible license is fine. I also found this StackOverflow answer that suggests the same.
That said, I'm not opposed to changing the license to EPL if that's more common in the Clojure world. But I can't promise that to happen in a timely manner if it's me doing it - I'd prefer to put what time I can carve out of my schedule for clostache into development.
Hah looks like we read the same stackoverflow post. The statement I thought was problematic with was:
That it [the library] is dynamically linked in to your application in such a way that the user can replace it with their own version if they want.
Unfortunately CLJS doesn't have an easy way to do that in advanced optimizations mode. You kind of just get a JS blob at the end that isn't easily swappable. It's why you see most JS libraries opting for MIT/BSD licenses - those tend to not impose any copyleft restrictions on binary blobs. The EPL doesn't either, which is nice.
True, didn't think of that :smile:
I'll contact the contributors and look into switching to EPL then.
@simonl2002, @annapawlicka, @jimmythompson and @trevor: I couldn't find your email address on GitHub, so I'll try it this way :smile: Could you comment here on whether you give your consent to this license change?
Wow thanks for the quick response. Thanks everyone! Just a few more - @michaelklishin @zeroem @liquidz @rgeoghegan quick ping - could you give consent on the license change?
