Handling binary libraries on each node supported platforms is really hard to do, and the solution is never gonna be perfect, our goal is to provide a good enough solution. Please take into account that we're doing this in our spare time, so instead of reinvent everything from scratch our module is using other modules and libraries to keep the required development effort as low as possible. So ditching dnfcn and rewriting exactly that just a bit of another way is out of scope of this project. But, as always, if you're gonna do it, and land a PR, that has any notable benefit over dlfcn, then we will merge it for sure.

About licensing, there is nothing wrong about including LGPL project in an MIT library, because doing so, doesn't make our library a "derived work" of that, so our library doesn't make its consumers as a derived work of that LGPL project, so LGPL terms doesn't apply to any of those.

A program that contains no derivative of any portion of the Library, but is designed to work with the Library by being compiled or linked with it, is called a "work that uses the Library". Such a work, in isolation, is not a derivative work of the Library, and therefore falls outside the scope of this License.

Didn't we try to move to libuv's threading functions when we switched to nan? That would mitigate this issue entirely.

@TooTallNate that was pthreads. :) dlfcn is about emulating dlopen in windows.

I said:

Some organizations prohibit the use of [L]GPL code, or require
legal review to do so. It would be helpful to warn them.

@unbornchikken replied:

About licensing, there is nothing wrong about including LGPL project in an MIT library, because doing so, doesn't make our library a "derived work" of that, so our library doesn't make its consumers as a derived work of that LGPL project, so LGPL terms doesn't apply to any of those.

A program that contains no derivative of any portion of the Library, but is designed to work with the Library by being compiled or linked with it, is called a "work that uses the Library". Such a work, in isolation, is not a derivative work of the Library, and therefore falls outside the scope of this License.

Yes, but the very next paragraph of the LGPL states:

However, linking a "work that uses the Library" with the Library creates an executable that is a derivative of the Library (because it contains portions of the Library), rather than a "work that uses the library". The executable is therefore covered by this License. Section 6 states terms for distribution of such executables.

I read that to mean that the node-ffi source code doesn't get sucked into LGPL-land, but the final compiled node add-on DLL does.

Regardless, my concern isn't just about the legal issues.

Many large companies have rules that require legal/management review/approval before using GPL'ed code. LGPL'ed code is often subject to the same process. Even if approval will eventually be granted, many people in these situations find it easier to just avoid GPL'ed code entirely. The fact that most of the node ecosystem uses BSD/MIT style licenses is one of the things that makes it attractive.

My suggestion stands: If you're going to bundle LGPL'ed code with your module, it would be helpful to mention that in your own LICENSE file. A simple "NOTE: Some bundled dependencies are licensed under different terms." is all I'm suggesting.

I'd be fine with adding a note to the LICENSE file. @mcnameej would you care to do a pull request? Otherwise I'll get around to it soon.

Yeah, It doesn't matter anyway.

A single line of pull request worth more than a thousand words! ;)