I think that the situation is more subtle than this. Consider, for instance,
this piece of code:
(defun nrepl-ido-form (ns)
"Construct a clojure form for ido read using NS."
`(concat (if (find-ns (symbol ,ns))
(map name (concat (keys (ns-interns (symbol ,ns)))
(keys (ns-refers (symbol ,ns))))))
(if (not= "" ,ns) [".."])
(->> (all-ns)
(map (fn [n]
(re-find (re-pattern (str "^" (if (not= ,ns "")
(str ,ns "\\."))
"[^\\.]+"))
(str n))))
(filter identity)
(map (fn [n] (str n "/")))
(into (hash-set)))))
This is an Emacs lisp function which returns a clojure form. The clojure in
this case is covered by
GPL because the file itself says that it is. Now, this GPL code is clearly
linked to "map", "filter"
and so on. This is allowable under GPL because "map" and "filter" are "Standard
Interfaces". So, GPL
code here is mere aggregation with clojure and not a derived work.
However, this is not true for a third party EPL library; these are not standard
interfaces, so you would
have an derived work, which would mean an EPL/GPL code basis which is not
legal. Personally, I do
not think this would be too much of a problem. The core of clojure is most of
what we would need.
Of course, this is my interpretation. For instance, I think nrepl.el is on
dodgy ground with its use of
complete.core which, as far as I can tell, is EPL. Obviously the nrepl.el
people think not.
Sorry to be a licence bore; I've had a lot of reason to think about this
recently, as I would like to use
GPL code in a clojure project that I am working on. I can do so, but if I do, I
cannot use third party
libraries which are EPL. None of this is to knock the EPL or the GPL. But they
are incompatible.
I agree with the rest of what you say; the clojure ecosystem is fairly rich,
and includes quite a few
Emacs hackers. Many of them also use Java directly (as well as via clojure).
And, by definition, anyone
who uses clojure is lisp literate. So, it might bring in more developers.
Phil
________________________________________
From: Steven Huwig [steven.hu...@gmail.com]
Sent: 30 April 2013 17:18
To: Phillip Lord
Cc: Paul Landes; JDEE Users; JDEE Development
Subject: Re: [jdee-devel] Call to Fork or simply for JDEE TODO items
I don't see the problem with using Clojure unless you're planning on making
JDEE a GNU project or distributing it with GNU Emacs. Just distribute the
Clojure portions under Clojure's license and JDEE under JDEE's license. There's
no way to link ELisp to Clojure anyway -- all the GNU-licensed code in Emacs
needs a socket to talk to the EPL-licensed code in Clojure (whether Clojure
itself or EPL-licensed libraries in Clojure).
EPL is still a free software license after all.
I think there's a much greater chance of a "halo effect" of Clojure developers
who use emacs improving a Clojure-based JDEE, than there is of ABCL being
significantly more effective at implementing JDEE.
On Apr 30, 2013, at 6:44 AM, phillip.l...@newcastle.ac.uk (Phillip Lord) wrote:
> Paul Landes <lan...@mailc.net> writes:
>> The basic idea would be to pretty much move all the things that beanshell and
>> semantic currently do to Java packages. That means using things like
>> compilation tools that come with the JDK and other OS packages (i.e. ASM) for
>> parsing, code completion, wizards, templates etc. The basic idea is using
>> straight Java packages for anything involving Java operations. This would
>> really slim down the code base and make it manageable.
>>
>> ABCL (common lisp implementation) would replace the now dead Beanshell
>> language, and frankly, seems like a better fit since its lisp and not Java.
>> Another benefit to this is it already works nicely with Slime so we could get
>> rid of the very (IMO) complex emacs -> beanshell IPC (emacs OO!) library.
>> Just
>> that would be a huge victory in my mind as I've spent hours and hours
>> debugging these two parts that stubbornly do not play well together (i.e.
>> beanshell start times and process hangups).
>
>
> Beanshell was good for it's time, but is now a big problem with JDEE.
> Another option over ABCL would be Clojure. There is quite a big emacs
> community behind it now, with tools like nrepl.el nicely separate from
> the clojure-mode. The Java integration is also very nice and, from a
> quick look at ABCL, better than ABCL. It's already got some stuff we use
> (a Javadoc lookup for instance).
>
> The negative side is that Clojure is Eclipse Public License. My
> interpretation of these two licenses is that we *could* use Clojure (the
> GPL talks of "standard interface" which would cover this), but we would
> be restricted for other packages which are EPL which could not be
> validly linked to JDEE.
>
>>
>> Another idea I had is to move everything to maven so there would be maven
>> integration (bridged through ABCL) for compilations. If others still want to
>> use Ant or something else we can talk about some abstraction layer.
>>
>> Many nice useful parts of JDEE would be folded in (i.e. syntax highlight,
>> maven integration or Malabar mode might be folded in for this).
>>
>> I'm glad to put this on paper and if there is sufficient interest by those
>> WILLING TO HELP and write the CL, Java bindings, and Emacs code then I'll
>> continue this process.
>
> The other thing that would be worth thinking about is what we *do not*
> need. My own feeling is that all the template stuff can be ditched;
> writing these templates was always a total pain in the ass, and why
> bother -- yasnippet does the job.
>
> As far as I can tell, it should be possible to get maven to launch the
> nrepl-server. So, all the dependency stuff, classpath and all that
> nastiness would go. The project would be maintained in pom.xml. An ant
> task wouldn't be too hard. This would mean a lot of the project
> switching stuff could be binned.
>
> JDEE cannot compete with Eclipse or netbeans. The Emacs ecosystem,
> however, can, especially for people who, like myself, use Java as one of
> many tools.
>
> Caveat to all of this, of course, is doing the work. I'm a very
> occasional Java user these days, so like everyone else, can only
> contribute a small amount of time.
>
> Phil
>
> ------------------------------------------------------------------------------
> Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET
> Get 100% visibility into your production application - at no cost.
> Code-level diagnostics for performance bottlenecks with <2% overhead
> Download for free and get started troubleshooting in minutes.
> http://p.sf.net/sfu/appdyn_d2d_ap1
> _______________________________________________
> jdee-devel mailing list
> jdee-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/jdee-devel
------------------------------------------------------------------------------
Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET
Get 100% visibility into your production application - at no cost.
Code-level diagnostics for performance bottlenecks with <2% overhead
Download for free and get started troubleshooting in minutes.
http://p.sf.net/sfu/appdyn_d2d_ap1
_______________________________________________
jdee-devel mailing list
jdee-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jdee-devel
