

Ruby-FFI is no longer maintained - Dylanlacey
https://github.com/ffi/ffi/commit/bef6f44505fd96eb16c044b1e1af9cbad2697bfe

======
w0rd-driven
This also seems to be an example of how _not_ to no longer provide support.
Close all the issues? Let no one take over? I guess a fork works but I've also
seen projects clearly taken over as-is with seemingly "official blessing." I
prefer the latter approach or at the very least, keep the thing untouched
until someone steps up. I could be late to the party and someone finally got
around to saying "tough shit, we're done here" after years of nothing. This
just feels cold to me. I don't need a sugar coated reason if you're honest.
You can easily say "all I get are windows support issues. Fuck windows!!!" and
it'd be a thousand times better than what's there.

~~~
byroot
Yeah it's not great, but I wonder if I don't prefer this over maintainers that
let their project die, don't answer PR/issues and never tell they would like
someone else to take over.

I mean, I understand that it's part of FLOSS, a maintainer owe nothing to his
users, but adding a line to a readme to explicitly say it would be
appreciated.

~~~
rmoriz
He probably burned out and the only feedback he got was about some irrelevant
licensing foo. I've run into this myself and this pretty much destroys any
motivation to hand over something, in which you have invested A LOT of time,
to someone else in a clear way without anger.

From a social aspect, github does not cover this. E.g. besides the technical
stuff there should be an easy way to donate or contribute money to an author
to honor his/her work.

Some communities, like Ruby or Perl, do have yearly events to honor people
that provide a lot of value to the community. A regular voting e.g. for the
"Ruby Developer of the month" \+ 100$ sponsoring could probably help to keep
motivation up and hard feelings down.

------
marti
Ruby >= 1.9 also has a built in libffi wrapper, "Fiddle"[1], which can
replicate basic Ruby-FFI functionality with some glue code[2]. There aren't
many examples, but I've successfully used it to call Windows API (GDI+)
functions.

[1] [http://ruby-
doc.org/stdlib-2.0.0/libdoc/fiddle/rdoc/Fiddle.h...](http://ruby-
doc.org/stdlib-2.0.0/libdoc/fiddle/rdoc/Fiddle.html)

[2] [http://www.slideshare.net/tenderlove/hidden-gems-of-
ruby-19/...](http://www.slideshare.net/tenderlove/hidden-gems-of-ruby-19/134)

~~~
rmoriz
It would be awesome if someone can extend this and provide some kind of
migration path for ruby-ffi users…

------
Argorak
So after reading this commit:

[https://github.com/ffi/ffi/commit/346c80ad6b8c0e6dc3c390b582...](https://github.com/ffi/ffi/commit/346c80ad6b8c0e6dc3c390b582a81b306e1ef5f9)

and this discussion

[https://twitter.com/bascule/status/393509979711213568](https://twitter.com/bascule/status/393509979711213568)

I have the impression that no one can safely fork ruby-ffi without opening
himself to legal trouble. It seems like the licensing of the project is a
horrible mess.

IANAL, so I hope I am reading this wrong?

~~~
logn
It's not that big of a deal. It's an LGPL-licensed codebase which incorporated
BSD-licensed modules (there's nothing wrong with that). Since LGPL places some
requirements on being intermingled with incompatibly-licensed software, the
author made sure to point out which parts were under the more permissive BSD
license so people could re-use those parts and not be subject to LGPL by using
his project as a whole.

In a nutshell, if you use an LGPL codebase, make sure either: (1) your code is
LGPL or under a compatible license or (2) that you only use the code on an API
level and dynamically link to it.

Btw, LGPL is a license accepted by many enormous communities, such as Qt.

If you want to fork this project, easiest route is to just re-apply the LGPL
license and fork after the point where notice of BSD parts was added, because
it's a violation of BSD to not mention their license.

IANAL

~~~
Argorak
I have no problem with the LGPL (beyond the occasional problem with legal, but
thats legals problem) or the dual-licensing in general.

The linked commit hints at additional problems with missing licensing etc. In
the absence of good documentation on this, a new maintainer has the problem of
not being able to make heads or tails of it if someone had claims on the code.

------
kawsper
It could be nice if Rubygems could show which gems that depends on a specific
gem. I have a feeling that quite a lot depends on FFI.

I know that we depend on FFI, because we use selenium-webdriver, which depends
on childprocess, which depends on FFI.

~~~
sqs
I'm helping build Sourcegraph, which lists the gems that depend on FFI here:

[https://sourcegraph.com/github.com/ffi/ffi/network/repos/in](https://sourcegraph.com/github.com/ffi/ffi/network/repos/in)

and can show where some of its main methods are used:
[https://sourcegraph.com/github.com/ffi/ffi/symbols/ruby/gem/...](https://sourcegraph.com/github.com/ffi/ffi/symbols/ruby/gem/FFI/Pointer/$methods/read_string)

and also for some other gems:

[https://sourcegraph.com/github.com/nex3/sass/network/repos/i...](https://sourcegraph.com/github.com/nex3/sass/network/repos/in)

[https://sourcegraph.com/github.com/lsegal/yard/network/repos...](https://sourcegraph.com/github.com/lsegal/yard/network/repos/in)

[https://sourcegraph.com/github.com/rails/rails/network/repos...](https://sourcegraph.com/github.com/rails/rails/network/repos/in)

It would be great if someone added this functionality to rubygems.org
(npmjs.org has it:
[https://npmjs.org/browse/depended/request](https://npmjs.org/browse/depended/request)).

The Ruby support is very alpha right now. It works for some (but not all)
popular gems, and it doesn't show transitive dependencies yet. Also, the list
of dependents isn't comprehensive, but it should be a good starting point. If
there are any specific gems you'd like to see dependents for, or any issues
you see, let me know.

~~~
lstamour
At a glance, there are perhaps 1400 gems that require or refer to ffi:
[https://www.google.ca/search?q=ffi+inurl:gemspec](https://www.google.ca/search?q=ffi+inurl:gemspec)

But that's the type of site I was trying to find before I resorted to Google.
I'd second that recommendation to add the functionality to rubygems.org ...
Maybe we need a pull-request? :)

~~~
sqs
I will probably eventually submit a PR for this feature at
[https://github.com/rubygems/rubygems.org](https://github.com/rubygems/rubygems.org).
If anyone else wants to get it started, I'd certainly help.

------
allr
More importantly, FFI 1.9.1 was released today
([http://rubygems.org/gems/ffi](http://rubygems.org/gems/ffi)) and completely
broke knife-solo, returning a huge stack trace ending with:

You may have encountered a bug in the Ruby interpreter or extension libraries.

reverting back to FFI 1.9.0 did the trick.

~~~
xentronium
1.9.1 is yanked as of now, which means no one can install it accidentally.

------
nnq
I never understood why aren't more Ruby extensions build on FFI instead of the
MRI C extensions way - it would make everything work seamlessly on JRuby or
Rubinius or Maglev and would also involve much less work.

...hope someone of the big Ruby backers take this project under their wing.

------
protomyth
Does anyone have a clue of why? I looked, and the only weird thing I can see
is the restoring of BSD license text to some files.

~~~
petercooper
I wonder if this is related to there being an extensive "discussion" on
Twitter a few days ago about ffi's LGPLv3 license. One thread to start from:
[https://twitter.com/bascule/status/393509979711213568](https://twitter.com/bascule/status/393509979711213568)
.. one of the concerns much later in the discussion seems to be how ffi
changed from BSD to LGPL at some stage.

------
jvoorhis
This is disappointing. I've created a number of FFI-based projects, and maybe
have taken it for granted. I checked the mailing list archives, and did not
see any warning signs or calls for new maintainers.

~~~
petercooper
This might explain some of it (not the original tweet but go much further down
in the discussion with regards to how the licensing was changed):
[https://twitter.com/bascule/status/393509979711213568](https://twitter.com/bascule/status/393509979711213568)

------
msie
Update: maintenance has been taken over by the JRuby team! Yay!

------
izietto
It's unfair that a so widespread project gets killed with so big lack of
informations; FFI implementation is essential in every mature development
platform IMHO.

------
ksec
OH Great, another Project closed due to stupid and insane License argument and
restriction.

------
yink
Does anyone know the reason for closing this project? Wayne Meissner appears
to have just protected his tweets
[https://twitter.com/wmeissner](https://twitter.com/wmeissner)

------
protomyth
Here is a link to the "Cleaning up licensing" issue
[https://github.com/ffi/ffi/issues/288](https://github.com/ffi/ffi/issues/288)

------
username223
As was said in the README: "The following people have submitted code, bug
reports, or otherwide contributed to the success of this project:"

But they can please to go die in a fire.

------
SmileyKeith
That's definitely unfortunate. Seems like a lot of stuff I've done
inadvertently requires ffi. And lately with Ruby 2.0.0-p247 on OS X Mavericks
ffi 1.9.1 has been crashing..

