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