alt Hacker NewsClosed 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.
Replies
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.
Dynamically and statically linked libs is hilarious in the context of webassembly running in the browser.
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)