Summary
The vendored HTTP library is Mongoose, which is GPL-2.0-only (or commercial), but the project is distributed under MIT. Static linking makes the shipped binary a GPLv2 derivative work, which conflicts with MIT distribution unless a commercial Mongoose license is held. Flagging it with a ready-to-go fix.
Details
vendored/mongoose/mongoose.c:
// SPDX-License-Identifier: GPL-2.0-only or commercial (Cesanta)
LICENSE: MIT, Copyright (c) 2025 DeusData.
Mongoose is statically linked into the binary, so every conveyed release artifact (npm / homebrew / chocolatey / AUR / PyPI) carries the conflict, and it propagates to anyone redistributing those binaries.
Scope
Mongoose is confined to a single file, src/ui/http_server.c (event loop, route match, reply). No TLS / websocket / advanced features are used.
Proposed fix
Two options:
- Obtain a commercial Mongoose license from Cesanta, or
- Swap the HTTP layer for a permissively-licensed library.
I've prototyped option 2 with civetweb (MIT; the MIT-licensed fork of the same Mongoose lineage) behind a thin compatibility shim, so the change is confined to that one file: ~60 lines changed, route dispatch and all reply call sites untouched. It builds clean, passes the ASan/UBSan test suite (0 sanitizer violations), and I verified the live server end-to-end (RPC dispatch, API routes, CORS, embedded assets).
Notes on fit with CONTRIBUTING
Flagging upfront since this touches "new vendored dependency" plus "build system": the first-party change is small (~90 lines: shim plus integration in one file); the bulk is vendored civetweb itself. Happy to wire it through the vendored-dependency integrity check and the security audit, and to add a route-level test, as part of the PR.
I already have option 2 working locally. I'd be glad to turn it into a PR per CONTRIBUTING.md, but I wanted to check the direction with you first. Which option do you prefer, and is civetweb acceptable? I can share the API-mapping writeup if useful.
Summary
The vendored HTTP library is Mongoose, which is GPL-2.0-only (or commercial), but the project is distributed under MIT. Static linking makes the shipped binary a GPLv2 derivative work, which conflicts with MIT distribution unless a commercial Mongoose license is held. Flagging it with a ready-to-go fix.
Details
vendored/mongoose/mongoose.c:LICENSE: MIT, Copyright (c) 2025 DeusData.Mongoose is statically linked into the binary, so every conveyed release artifact (npm / homebrew / chocolatey / AUR / PyPI) carries the conflict, and it propagates to anyone redistributing those binaries.
Scope
Mongoose is confined to a single file,
src/ui/http_server.c(event loop, route match, reply). No TLS / websocket / advanced features are used.Proposed fix
Two options:
I've prototyped option 2 with civetweb (MIT; the MIT-licensed fork of the same Mongoose lineage) behind a thin compatibility shim, so the change is confined to that one file: ~60 lines changed, route dispatch and all reply call sites untouched. It builds clean, passes the ASan/UBSan test suite (0 sanitizer violations), and I verified the live server end-to-end (RPC dispatch, API routes, CORS, embedded assets).
Notes on fit with CONTRIBUTING
Flagging upfront since this touches "new vendored dependency" plus "build system": the first-party change is small (~90 lines: shim plus integration in one file); the bulk is vendored civetweb itself. Happy to wire it through the vendored-dependency integrity check and the security audit, and to add a route-level test, as part of the PR.
I already have option 2 working locally. I'd be glad to turn it into a PR per CONTRIBUTING.md, but I wanted to check the direction with you first. Which option do you prefer, and is civetweb acceptable? I can share the API-mapping writeup if useful.