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.
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.
[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/...
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?
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
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.
"Postmodern" has it from the linked twitter thread: "they [are] probably confusing LGPL with GPL/AGPL, or are afraid of getting Stallman cooties."
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.
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.
Just a guess, but maybe someone was initially confused, and removed the BSD license rather than simply adding the LGPL license?
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.
I know that we depend on FFI, because we use selenium-webdriver, which depends on childprocess, which depends on FFI.
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.
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? :)
Are these only gems where the gem source code is in Github?
edit: assuming you're using Bundler, that is. If you're not, fix that first ;)
Can you not rely on childprocess (or selenium webdriver) to handle their own dependancies appropriately?
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.
I guess the reason that I am a bit uncomfortable, is because FFI in particular feels very basic and fundamental.
You may have encountered a bug in the Ruby interpreter or extension libraries.
reverting back to FFI 1.9.0 did the trick.
...hope someone of the big Ruby backers take this project under their wing.
But they can please to go die in a fire.
