Hi — thanks for maintaining this. While doing a license audit before adopting uiohook-napi in a commercial desktop app, I found a packaging gap that downstream consumers are very likely to miss.
What I observed. package.json declares "license": "MIT". That is accurate for the wrapper sources in src/lib/**. But the published tarball also contains libuiohook, which is LGPL-3.0-or-later — from libuiohook/include/uiohook.h in the tarball itself:
libUIOHook is free software: you can redistribute it and/or modify it under the terms of the GNU Lesser General Public License as published by the Free Software Foundation, either version 3 of the License, or (at your option) any later version.
And binding.gyp links it statically ('target_name': 'libuiohook', 'type': 'static_library'). So the prebuilt artifacts in prebuilds/{darwin,linux,win32}-*/uiohook-napi.node are LGPL "Combined Works" under LGPLv3 §4, not MIT-only binaries.
The gap. Checking npm pack uiohook-napi@1.5.5, the only license file in the tarball is package/LICENSE (MIT, the wrapper). There is no copy of the LGPL, no copy of the GPL, and no notice that libuiohook is included or that it is LGPL-licensed. LGPLv3 §4(c)/(d) asks for exactly those.
The practical consequence is that automated license scanners (and the npm registry page) report this package as plain MIT. A downstream team can adopt it, ship it in a proprietary product, and never learn they have taken on LGPL static-linking obligations. That is the outcome I was one step away from.
Suggested fix (all cheap, no code changes):
- Add libuiohook's
COPYING.md (GPL-3.0) and COPYING.LESSER.md (LGPL-3.0) to the files array so they ship in the tarball.
- Add a short
NOTICE or README section stating that the addon statically links libuiohook, that libuiohook is LGPL-3.0-or-later, and where to get its corresponding source.
- Consider an accurate SPDX expression in
package.json, e.g. "license": "MIT AND LGPL-3.0-or-later". This is the highest-value change — it is what scanners read.
Happy to open a PR for any of the above. To be clear, I'm not suggesting libuiohook's license is a problem or that you should relicense — the ask is purely about the notices and metadata that travel with the published artifact.
Hi — thanks for maintaining this. While doing a license audit before adopting
uiohook-napiin a commercial desktop app, I found a packaging gap that downstream consumers are very likely to miss.What I observed.
package.jsondeclares"license": "MIT". That is accurate for the wrapper sources insrc/lib/**. But the published tarball also containslibuiohook, which is LGPL-3.0-or-later — fromlibuiohook/include/uiohook.hin the tarball itself:And
binding.gyplinks it statically ('target_name': 'libuiohook', 'type': 'static_library'). So the prebuilt artifacts inprebuilds/{darwin,linux,win32}-*/uiohook-napi.nodeare LGPL "Combined Works" under LGPLv3 §4, not MIT-only binaries.The gap. Checking
npm pack uiohook-napi@1.5.5, the only license file in the tarball ispackage/LICENSE(MIT, the wrapper). There is no copy of the LGPL, no copy of the GPL, and no notice that libuiohook is included or that it is LGPL-licensed. LGPLv3 §4(c)/(d) asks for exactly those.The practical consequence is that automated license scanners (and the npm registry page) report this package as plain MIT. A downstream team can adopt it, ship it in a proprietary product, and never learn they have taken on LGPL static-linking obligations. That is the outcome I was one step away from.
Suggested fix (all cheap, no code changes):
COPYING.md(GPL-3.0) andCOPYING.LESSER.md(LGPL-3.0) to thefilesarray so they ship in the tarball.NOTICEor README section stating that the addon statically links libuiohook, that libuiohook is LGPL-3.0-or-later, and where to get its corresponding source.package.json, e.g."license": "MIT AND LGPL-3.0-or-later". This is the highest-value change — it is what scanners read.Happy to open a PR for any of the above. To be clear, I'm not suggesting libuiohook's license is a problem or that you should relicense — the ask is purely about the notices and metadata that travel with the published artifact.