Ruby-FFI is no longer maintained

w0rd-driven 12 years ago |

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 12 years ago | |

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 12 years ago | | |

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 12 years ago |

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

rmoriz 12 years ago | |

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

Argorak 12 years ago |

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?

logn 12 years ago | |

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 12 years ago | | |

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.

rtb 12 years ago | |

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

justincormack 12 years ago | | |

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.

belorn 12 years ago | | |

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.

protomyth 12 years ago | |

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.

belorn 12 years ago | | |

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?

protomyth 12 years ago | | |

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.

Argorak 12 years ago | |

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.

kawsper 12 years ago |

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.

allr 12 years ago |

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.

xentronium 12 years ago | |

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

nnq 12 years ago |

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 12 years ago |

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 12 years ago | |

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.

jvoorhis 12 years ago |

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 12 years ago | |

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

msie 12 years ago |

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

izietto 12 years ago |

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 12 years ago |

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

yink 12 years ago |

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

protomyth 12 years ago |

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

username223 12 years ago |

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 12 years ago |

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