Ruby-FFI is no longer maintained | Hacker News Reader

Ruby-FFI is no longer maintained

github.com

70 pointsDylanlacey46 comments

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.

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.

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.

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...

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

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

So after reading this commit:

https://github.com/ffi/ffi/commit/346c80ad6b8c0e6dc3c390b582...

and this discussion

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?

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

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.

I don't think that's the case. It appears to be LGPL + BSD. That should be fine for pretty much any use.

"Postmodern" has it from the linked twitter thread: "they [are] probably confusing LGPL with GPL/AGPL, or are afraid of getting Stallman cooties."

No it is not LGPL+BSD according to the license, it is LGPL3 https://github.com/ffi/ffi/blob/master/LICENSE

Parts of it being BSD does not mean it is dual licensed, it just means you can remove the BSD parts and reuse them elsewhere as BSD; you cannot just take BSD files and strip out the license as the terms say the license must remain included.

The license of the combined work is under LGPLv3, but the individual code parts is either under LGPLv3 or Modified BSD License (or LGPL+BSD for short).

Its correct however that one can not remove the actually license text from the BSD licensed code. Doing so would be a license violation of the BSD license terms #1.

This is the good part about BSD for FOSS projects. One do not need to do any active action to be in compliance with the license. Do changes, add any licenses, and so long the license text on the BSD source code is intact, you are in the green.

It looks like given this https://twitter.com/luislavena/status/394228584199372800

That the old BSD header and copyright were removed and LGPL added. You can only do this if you have the agreement of all copyright holders. The BSD does not allow you to remove the copyright.

Sadly, I agree with your conclusion, this is a minefield.

Looking at the repo now, it seems to include both the LGPL and BSD header on those files mentioned in the diff.

Just a guess, but maybe someone was initially confused, and removed the BSD license rather than simply adding the LGPL license?

Probably, it seems a common thing with the BSD that people forget they cannot remove the header without all the authors permissions.

If someone was going to fork it, they probably should go back before the license change and solve whatever bug fixes in an independent manner just to avoid the whole thing.

Answering my own to bring some conclusion to this:

https://github.com/ffi/ffi/issues/288

Seems like the current maintainers are on a good way of actually contacting everyone to agree on a license change.

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.

Is this a big problem for someone in your situation?

Can you not rely on childprocess (or selenium webdriver) to handle their own dependancies appropriately?

Well sure, from the same perspective, the way this usually works is someone will take over the project -- whoever "needs it the most when they discover an issue" -- and so it's not necessarily anyone's problem. That is, after all, the somewhat selfish nature of Open Source.

But I'd say this is a problem if one wants to ensure compatibility in Rubyland with other languages and processes on different environments, or that they're using the latest and most correct code for their situation.

This gets hairier if the gem forks on github, and you've multiple fixes in multiple branches ... Rubygems aren't really set up to deal with this. Bundler helps, though.

No, not really a problem for me, I would expect childprocess to change their dependencies if needed.

I guess the reason that I am a bit uncomfortable, is because FFI in particular feels very basic and fundamental.

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

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/...

and also for some other gems:

https://sourcegraph.com/github.com/nex3/sass/network/repos/i...

https://sourcegraph.com/github.com/lsegal/yard/network/repos...

https://sourcegraph.com/github.com/rails/rails/network/repos...

It would be great if someone added this functionality to rubygems.org (npmjs.org has it: 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.

At a glance, there are perhaps 1400 gems that require or refer to ffi: 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? :)

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

Had a play around on SG and it works really well; nice project. What JS framework, if any, are you using?

Thanks! We are using AngularJS with UI-Router and Backbone 3. The backend is in Go, with a native language component for each of the languages that we support (currently Python/Go/JavaScript/Ruby).

which lists the gems that depend on FFI

Are these only gems where the gem source code is in Github?

Pretty much (it also includes gems hosted on Bitbucket or Google Code).

Hmm. I was thinking it might be useful here: http://www.ruby-doc.org/gems/

Awesome site! It would be great if you added a link to Sourcegraph there. We're going to have language-specific homepages (sourcegraph.com/ruby) and I can let you know when that's ready if you would prefer to link to that.

What I was hoping was that for any given gem you could see, as part of the rendered docs, what other gems it relies on.

Basically, enhance the default docs that are generated by rdoc with additional information about the gem.

One-stop shopping, so to speak.

I'll let you know if/when I make that patch to rubygems.org (or if it's not possible, when sourcegraph.com could provide you with that info).

You can tell it for a given project by looking in Gemfile.lock. It shows all the gems you explicitly requested in your Gemfile, and what dependencies each one pulled in.

edit: assuming you're using Bundler, that is. If you're not, fix that first ;)

There is a list of several gems depending on ffi ( https://www.ruby-toolbox.com/projects/ffi ), mostly system stuff: Popular gems depending on ffi childprocess, rb-inotify, rb-kqueue, rb-fchange, ethon, spoon, minitest-chef-handler, win32-process, libnotify, nfqueue, net-ping, rubypython, sys-cpu, sys-uname, gssapi

More importantly, FFI 1.9.1 was released today (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.

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

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.

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.

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 .. one of the concerns much later in the discussion seems to be how ffi changed from BSD to LGPL at some stage.

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.

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

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

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.

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

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

Here is a link to the "Cleaning up licensing" issue https://github.com/ffi/ffi/issues/288

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.

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..

Reply on news.ycombinator.com