- 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.

I'm slowly leaning towards eventually just adopting MPL which is kind of weaker than LGPL but more friendly for iOS, course I mostly just default to MIT license these days. I prefer to let my users use my software however they want without fear that if they someday overhaul my code and build something that works for them, that they would lose it.

I wonder if you can keep your application itself closed source, but make an open-source adapter that handles the interaction with FFMPEG.

I'm not super familiar with open source licensing, and IANAL, so make sure to do your own research :)

As an example, I believe Audacity required me to install ffmpeg manually myself, and add it to my path. This is slightly different since Audacity itself is also open source. But could be helpful to reference.

Prompting the user to install, or auto-installing FFmpeg separately, rather than bundling the binary. The problem is FFmpeg can be configured in so many ways and the general install binaries are usually LGPL compatible.

Mmmm...potential commercialisation? Always find it curious that people expect to get source code for free in ways that they don't do for other work (ask George Martin to release his drafts and notes).

VidStudio invokes FFmpeg — a free multimedia framework — to handle certain video and audio processing operations. FFmpeg is licensed under the GNU General Public License v2 (or later).

The FFmpeg WebAssembly binary is not hosted or redistributed by VidStudio. Your browser fetches it directly from the public npm mirror at cdn.jsdelivr.net the first time you use a feature that requires it.

FFmpeg source code is available from ffmpegwasm/ffmpeg.wasm (the WebAssembly port) and git.ffmpeg.org/ffmpeg.git (upstream FFmpeg). The full text of the GPL v2 license is available at gnu.org/licenses/gpl-2.0.

Did you mean to say that it is a problem? From the rest of your comment, and in the context of GP's comment, it sounds like commercializing is NOT a problem.

Hence why I asked the question... And not everybody does everything for commercial reasons, so it would be dumb to assume that and therefore not ask the question.

> Always find it curious that people expect to get source code for free in ways that they don't do for other work (ask George Martin to release his drafts and notes).

Where in my question did you get that I expect to get source code for free in ways that I don't for other work?

But regardless, you do know that open source is a common thing right? People open source things all the time, especially on HN.

Also OP already says they don't do any uploading of your videos to the cloud, so this thing already runs local-only. It's not like there is a shortage of video editors around (including ... open source ... video editors)

Most people would want you to upload the code to github, then they can star and clone it with ease. But you don't have to have an issue tracker, and you certainly don't have to read any of the issues or pull request. You can ignore or disable that.

I think even just having a up to date .zip with all the code would be technically enough.

You might just find you end up with some folks who genuinely want to help out, though.

Apart from ensuring there’s not anything confidential in the code like API keys (which you shouldn’t have anyway, unless it’s just in comments) it won’t take any extra work unless you want to put effort into that side of things

https://news.ycombinator.com/item?id=42207002

PS: i am that guy :-)

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.

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

Anyway, OP doesn't do most of the things FFmpeg lists under their "License Compliance Checklist".

For example, we're complaining about a licensing issue for an app that can run locally (in your browser, no uploads needed). The licensing issues can easily be side-stepped by the the developer if they chose instead to do all the media manipulation in the backend.

In the end, for the user this means they have to upload & trust a random service with their data, potentially can't get raw data out, and other negative side-effects of lock in.

Legitimately asking, which points and how are they expected to handle it for this type of app (assuming they want to keep it closed source)? As far as I understand it they just need to credit the libraries?