Closed source is fine, but there are a few other things that are required of LGPL, some of which are

- Provide links to the source of the version of ffmpeg you used in your code

- User should be able to replace the ffmpeg libs with his own compatible builds if you're using dynamically linked libs. For statically linked libs, you need to provide the tools to re-link against a compatible build.

I went through an LGPL review recently so some of this is fresh in my memory, but please correct me if I'm wrong.

Thank you for pointing this out, to be completely honest, I did not consider licensing because the website started as a collection of tools I built to run locally and get into video/audio codecs then I realised it is already a decent collection of tools that other people might want to use too. But I will be making the needed changes to comply fully tonight. At least I comply with this: `Do not misspell FFmpeg (two capitals F and lowercase "mpeg")` I realised I have some more reading to do regarding GPL vs LGPL because of the wasm project.

It should be possible to comply with LGPL without publishing the source code of the whole application. Either by running the application and ffmpeg in different isolates (wasm processes), or by offering a way to merge (link) the wasm code of the closed-source application with a user compiled FFmpeg wasm build.

Different isolates might even be enough to satisfy GPL, similar to how you can invoke FFmpeg as a command line tool from a closed application. Though that feels like legally shaky ground.

LGPL permits that.

However, some popular codecs use GPL, which, if enabled, would require to distribute the rest of the code under it as well.

LGPL allow you to use the library in closed source.