Comment by elpocko
7 hours ago
> FFmpeg compiled to WebAssembly handles final encode
FFmpeg's license is the LGPL 2.1. VidStudio looks like closed source software, I couldn't see any indication that it's free software. You're distributing this software to run in the client's browser. I'm not a lawyer but I think you're in breach of the terms of the LGPL.
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.
I knew about the soft copyleft (the source code requirements) but didn't know there was the requirement to have libs be replaceable. Now I want to know how useful that would be in reverse engineering closed systems (particularly nintendos, since I've always had an interest in the homebrew scene there)
iirc, the video player application VLC used to come without any mpeg support, and you had to go through a process to download ffmpeg separately ...not sure how easy it made it to replace individual libs, but I'm also not sure the license requires you to make it easy.
1 reply →
Dynamically and statically linked libs is hilarious in the context of webassembly running in the browser.
You can have multiple WASM modules communicating with each other (though you would probably need extra interop code?), or statically link them into a single module, the concepts work mostly the same
1 reply →
I think you're right, also an interesting aside: LGPL software is even trickier on the iOS app store, where its out of your control to "let the user link" the software. I guess in that case the only real way is to somehow give them access to the linkable files or allow them to pull in your copy of an LGPL library, but for them to run it on their device, good luck...
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.
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.
You should look into how other companies and tools that use FFMPEG handle this situation.
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.
Yes, Audacity definitely requires that. It can't open or save mp3s unless you separately install ffmpeg.
Thank you, I guess I won't be fixing any bugs tonight but at least I will figure out how to comply. I appreciate the help for real!
Wonder this guy is doing it? Or is it also not open sourced?
https://news.ycombinator.com/item?id=42207002
that guy is not including ffmpeg and is not encoding in browser. What he is doing is generating a ffmpeg command that you can run on your cli/scripts etc.
PS: i am that guy :-)
Any reason not to just open source it? Personally I'd love to hack on it :-) IANAL, but IMHO AGPL would be a good fit here as it complies with LGPL and also ensures nobody besides you (the copyright holder) can stand it up for profit without contributing back).
> Any reason not to just open source it?
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).
10 replies →
I never maintained an open source project and not sure how to even do it properly. I am also not sure how much effort would I have to put to an open source project. I imagine I would need to collaborate with a pretty much anyone who has an interest in the area. Again not that I mind just not sure how much time I have to spare. Right now this is a really slow process and tbh I have to rely on manual testing at least for the editor.
2 replies →
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.
Thanks for sharing. Will look into it
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 permits you to distribute binaries, but you can't distribute the software as an opaque binary blob with no reasonable way to modify it. What even is the equivalent of a shared library that a user can replace when software runs in the browser?
Anyway, OP doesn't do most of the things FFmpeg lists under their "License Compliance Checklist".
Not disagreeing with you, but cases like these really highlight how (L)GPL can nudge vendors into doing more closed solutions with greater lock-in.
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.
> Anyway, OP doesn't do most of the things FFmpeg lists under their "License Compliance Checklist".
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?
2 replies →
LGPL allow you to use the library in closed source.
Yes but you must distribute in a way where it's trivial to link in another version of the library. So a single wasm blob is a violation.