clojure's own EPL v1 license is incompatible with GPLv3 and AGPL by extension. so it technically makes things built with clojure incompatible with these licenses as i understand it. A/GPL needs all the underlying things to be compatible. iirc the classpath exception in openjdk for example uses gplv2 and iirc has issues with v3. i'd use LGPL if going the GPL route

So how does metabase use it? https://github.com/metabase/metabase

might be in parts i suppose. these things have always confused me too and always sidestepped it with other licenses 😛

lemme look up a thread here i vaguely remember

Same, but I want to understand it one day

the tweet seems to be deleted but this is the closest thing i can find: https://groups.google.com/g/clojure/c/TfPK-ljC46I

"Based upon the position <> of the Free Software Foundation, you may not combine EPL and GPL code in any scenario where linking exists between code made available under those licenses. The above applies to both GPL version 2 and GPL version 3."



"However, developers who want to release GPL-covered plug-ins for Eclipse can address this issue by providing an additional permission with their license <> that grants users permission to combine their work with Eclipse in this way." 

i suppose this is how metabase could do it maybe?

I think so, the AGPL license text lists all explicit dependencies

This reminded me of https://github.com/hraberg/deuce/issues/20 which looks like it stalled due to licensing issues?

@UK0810AQ2 Did you (and others in this thread) see the recent talk by Martin Clausen at London Clojurians where he talks about the implications of various open source licenses (and EPL in particular)?

https://www.youtube.com/watch?v=m478BHGR3XU

He didn't say it explicitly, but didn't he imply that projects like datomic may violate clojure's EPL license?

EPL is a lot more "copyleft" than most people think, according to Martin, and he suggested that if you distribute a program built with Clojure -- that contains Clojure itself, as uberjars do -- then your own application needs to be made available in source form if users ask for it.

(I don't agree, because I don't think it creates a "derivative work" -- and EPL2 seems to have gone to some lengths to clarify that intent, but EPL1 is legally ambiguous so I suspect it would have to be clarified in the courts if/when someone brings a lawsuit)

It stinks that choosing a License is both a) usually a good idea and b) incredibly confusing. There's lots of conflicting advice from both experts and many, many non-experts.

EPL2 seems to make it clearer that EPL is not intended to cover your files if bundled with EPL-licensed code, only files from the EPL-licensed code that you modified (if any), and so the burden is only to make the (potentially modified) EPL-licensed files available -- which can be done by acknowledging Clojure in your docs/license and pointing to the public repo. If you build a project using a modified version of Clojure, it's pretty clear cut that all those modifications must be made available in source form (if anyone asks for them).

Haven't, but will, thanks

Lawyers are very conservative about this stuff tho'... When I worked at Adobe, I had to get involved in a few OSS license review processes and GPL code was pretty much a "no-no" for them and even LGPL was very problematic -- to the point where my team asked an OSS project to change its license (to ASL2) so we could use it without upsetting the legal team.

Thinking about modified version of a dependency in the context or a REPL makes my teeth ache, I can always (in-ns ,,,) and monkey-patch a function

The key part of these licenses is distribution. If you're not distributing anything, you're (mostly) not obligated.

So in services this is not an issue, unless something is licensed under the AGPL

i suppose AGPL affects more than distribution too? its for servers providing services?

(this is why I try to avoid GPL, LGPL, and AGPL 🙂 )

I want to license everything I write under AGPL but I have no idea if I can so I just default to EPL2

I tend to use ASL2 for stuff that I don't care about folks incorporating into their own code and EPL for stuff where I do care 🙂

for me https://www.juxt.pro/blog/prefer-mit/ had a big lasting impact on me and works out well 😄

e.g., my usermanager example is ASL2, but next.jdbc and HoneySQL are both EPL. My build-clj wrapper and the log4j2 plugin cache merger lib are both ASL2 but deps-new is EPL...

(but, yeah, OSS licensing is a complex minefield, unfortunately)

re: AGPL: as long as you’re not distributing uberjars I wouldn’t expect much issue. FWIW all of my code falls under either “Proprietary” (code I write for my employer) or “AGPL” (code I write on my own time and resources), even after thinking long and hard about open source licenses [insert the usual “this is not legal advice” paragraph here]

AGPL adds in the “network access“ aspects too. If that software is accessed as a service it still falls under the GPL clauses. Which is more than jar distribution.

the issue with standalone jar distribution is that you’d be bundling EPL code (clojure) which is NG… but providing access to your source code and relying on clojure as a “major component” should be OK, as far as I understand it

yep, agreed there. the network clauses of the APGL is what bothers me a bit