Sean Corfield <s...@corfield.org> writes: > On 8/18/15, 3:04 PM, "Phillip Lord" <clojure@googlegroups.com on behalf of > phillip.l...@russet.org.uk> wrote: > > >>There *is*, however, an issue with use of many parts of the Clojure >>Ecosystem. > > Even if the "Clojure/core" definition extended to Contrib libraries, under > this consideration, you couldn’t write a non-trivial Clojure program with just > the core/contrib namespaces without duplicating a LOT of code that is already > out there. So I believe Bodil is correct _in practice_ even if she may be > _technically_ incorrect in theory.
I think that you are correct that the use of EPL has consequences, and I would have assumed that what you said was correct, but then I checked up. For instance, Magnar was worried about this use of GPL for his site. http://www.parens-of-the-dead.com/ So, I went and looked it up and actually neither of the two libraries he is using are EPL. So, already non-EPL licenced Clojure libraries are more widespread than I thought. It would be interesting to do a survey of license use. I am sure EPL is common, partly because Clojure uses it, and partly because leiningen puts it in as the default (bad leiningen!). >>For example, I believe that releasing a leiningen plugin >>under GPL would be impossible, since lein is EPL and is not part of the >>standard interface (I pick lein as an example here, not for any other >>reason). > > Actually, based on what both the Eclipse Foundation and the Free Software > Foundation say about writing GPL plugins for Eclipse, I think this is a case > where you _could_ write GPL Clojure code, albeit under a slightly modified GPL > (see my response to Kyle, with links to both Eclipse and FSF websites > discussing this exact situation). Yeah, it's a variant on the "classpath" exception. > Again tho’, you’d need to avoid the greater ecosystem of EPL-covered Clojure > libraries and stick to just core (and maybe contrib). > >>It's an unfortunate situation in some ways, but one that has been >>entered into consciously. Doubly unfortunate in that it is largely for >>technical reasons, as far as I can tell, rather than a deliberate desire >>to EPL and GPL to be incompatible. Such is life. Licences are more >>complex than code. > > EPL is more "business-friendly" than GPL insofar as companies can combine EPL > code into their (commercial) products much more easily than GPL code, so I’d > view this as much less of a technical decision than a solid business decision, > made for the benefit of Clojure at large, so it can spread into more > companies. I understand that. I'd rather not discuss motivations, lest we end up in yet another long license thread. I am only interested in consequences. > (caveat: IANAL but I’ve been through OSS license audits at companies that are > large enough to care deeply about this sort of stuff — unfortunately) Agreed. My concern with the EPL is (partly) that it is GPL incompatible, but more the *reason* that it is incompatible. It has a "choice of law" clause. Maybe that's fine for the US. But in the UK? I have no idea at all whether it means anything at all (probably it does not), but possibly it does. It's not likely to change now as I said, so there is probably nothing that can be done about it. Phil -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
