Alright, well, it is what it is. When it comes time to create a version of
JRuby that can be built without JNA and JFFI I'll start making a lot of
noise in IRC.
Wayne Meissner wrote:
Of course, a gym bag full of cash is always useful in persuading me to
do the extra work and change the license to whatever is most
convenient.
There ya go, Fletch, just cough up some dough.
JFFI in jruby isn't a short term solution anyway - its not going to go
in until
Currently its going to be LGPLv3.
Thats mostly so I can easily borrow code from e.g. JNA if/when I need
to to flesh out its capabilities - otherwise I will have to reinvent
the wheel, and I'm lazy, so I don't like having to do extra work
unless I have to. The aim of JFFI was performance vs JNA, n
Wayne, if you're out there reading this, what kind of license are you
planning on for JFFI?
Charles: I'll stay in touch in IRC when it comes time to start severing JNA
from JRuby.
On Sun, Aug 3, 2008 at 8:39 PM, Charles Oliver Nutter <
[EMAIL PROTECTED]> wrote:
> These are largely questions for W
Matt Fletcher wrote:
I've discussed this a bit with headius and others in IRC over the last
two days. It sounds like there may be a better way out: JFFI. I do not
know much about the JFFI project since I cannot find any information
about it on the web. But headius is saying that JFFI is not dep
JRuby is currently using JNA for performing native operations like
File.executable?. It looks like there are also some references to JNA in the
src/org/jruby/ext/ffi code. This is a problem for me now because JNA is
licensed as LGPL. As far as I know, JRuby's CPL license is the most
restrictive lic
