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.

▲

elpocko 7 hours ago | parent [-]

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

▲

senko 6 hours ago | parent | next [-]

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.

▲

trinix912 7 hours ago | parent | prev [-]

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

	▲	elpocko 7 hours ago \| parent \| next [-]
		The important thing is there has to be a clear separation between the proprietary parts and the LGPL parts of the app, and they have to provide a way to replace the LGPL parts. I have no idea how this is usually handled in the case of browser-based apps.
	▲	actionfromafar 6 hours ago \| parent \| prev [-]
		User must be able to replace the LGPL library with their own version of the library.