If you need legal advice, you should probably ask a lawyer since most clojure programmers here probably aren't qualified to opine on copyright law. You can try asking on https://ask.clojure.org/. Also, there was a london clojurians talk about open source licenses about a year ago which you can check out, https://youtu.be/m478BHGR3XU?si=hfNQaQ3QTH2t1Cpd.

A more appropriate link from the EPL FAQ than the one mentioned by your previous post: https://www.eclipse.org/legal/eplfaq.php#CODEGEN tl;dr: It is reasonable to assume that similar artifacts do not constitute derivative work, however you should still ask your lawyer.

Maybe @U04V70XH6 can opine. IIRC, the company he works for has been seriously considering CLJS.

I worked for Adobe for a while and their legal team had very strong opinions about certain OSS licenses, even for use in "products" that were web-based and not packaging and sold directly to customers. They actually made us petition an OSS project to change from LGPL to ASL for use in one particular project (it had a code generation aspect -- so we would be using code that the lawyers felt was covered by LGPL and then mixing our own code in). I personally wouldn't consider Clojure/ClojureScript macros to fall under derivative work from a licensing p.o.v. since that is arguably "just part of compilation" and there's no legal problem using EPL tools to produce bytecode from your own proprietary source code as far as I understand things. There are certainly some closed source apps out there built from Clojure/ClojureScript and it would be incredibly counter-productive for Rich or Nubank to sue people building those -- Clojure is intended for "makers" after all. If you take existing EPL source code and modify it and distribute it as part of your app -- that's a no-no from a licensing p.o.v unless you contribute those modifications back. As long as you are using tooling and libraries exactly as-is, without modification, then EPL is "fine". All that said, while I've worked closely with lawyers at times on OSS licensing audits etc, I am not a lawyer and if you really have concerns, as both previous posters have said, you should consult a lawyer who is familiar with OSS licensing issues.

(and my current company's potential use of CLJS would be for part of a web app and, if we adopt it at any point, we would certainly contribute back any modifications we made to EPL source)

Multiple ways to handle that, somewhat depends on what you deem to be "app configuration". > Put the configuration in a .edn file. That's reasonable. > Ok, but where exactly? Anywhere on the classpath that's active during compilation, so that io/resource inside a macro that's being executed during CLJS compilation can find it. > And how the Clojurescript code would be supposed to retrieve the file? Just create a simple macro that slurps the file, parses the EDN data, and returns is. Switch between them in dev/prod like described here: https://clojurians.slack.com/archives/C6N245JGG/p1707292655064989?thread_ts=1707252952.862389&cid=C6N245JGG and below. Alternatively, you can switch the classpath. Some, including Thomas, don't like that approach but I myself don't care that much, I already have Logback configs that depend on the classpath, there doesn't seem to be an elegant way around it. > And how would that work for deployment? You compile with a config that's meant for the deployment target, then you deploy the resulting JS bundle there. The bundle itself will have all the config data baked in. > Put the configuration in a .cljs file, using def forms. Also reasonable, especially if the config has dynamic parts. > I think it would be harder to have two different configurations for dev and prod Nah, same exact story as above.

thanks a lot @U2FRKM4TW

And if some parts of the config depend on some values available only at run time, e.g. some value retrieved from the backend, you can do it via embedding some EDN right in the HTML - again, just like Thomas shows in the thread that I mentioned above.