With the reference encoder licensed under LGPLv3, I doubt any browser team will be able to incorporate this work into their product. They would need to do a full clean room reimplementation simply to study it (since GPLv3 seems unacceptable to them, and LGPLv3 can’t coexist with GPLv2, and so forth and so on). It’s really unfortunate that the FLIF team chose such a restrictive license :(
EDIT: Their reference JS polyfill implementation is LGPLv3 as well, which may further harm adoption.
The decoder-only version of the reference implementation (libflif_dec) uses the Apache 2.0 license (specifically for this reason, I'd assume). Browsers shouldn't need to encode FLIF images very often, so decoder-only would be fine for that use case.
Not even the most restrictive copyleft license hampers evaluation. You are literally free to do whatever you want with the program on your own hardware. Its only when you start redistributing that the license kicks in.
What degree of rewriting would be necessary to neutralize the LGPLv3 license restrictions? Would I be sued if I used the same logic flow but handcrafted every statement from a flow diagram generated from the source code?
If I study the source and then make a single change to my own algorithm to incorporate the secret sauce in order to test its efficacy using my existing test suites, have I infected my own codebase with LPGLv3?
How can I test this code in the real world with real users if I’m not allowed to redistribute it? Would I be required to pay users as contractors to neutralize the redistribution objection?
Etc, etc.
EDIT: Neutralizing LGPLv3 would be necessary to combine this code with GPLv2 code and many other OSF-approved open source licenses, which is why that particular line of reasoning is interesting to me.
A web browser doesn't need to "evaluate the efficacy" of an image codec. It either supports it or it doesn't, and in the former case it only needs to decode, which means it only needs to incorporate Apache 2.0 licensed code.
Like I said: they shouldn't need to encode images very often, and that doesn't seem like all that much of a common use case (nor would it preclude a browser from implementing decoding and just not supporting FLIF for encoding-dependent functionality like that).
It does not seem to do consensus to me, just speculations. And even if it would be a consensus, there is way to link statically with LGPL and still respect the license.
Safari is by Apple, who seems to have decided to deprecate and replace every open source component that relicenses as v3 (such as OpenSSL and bash); their chances of allowing their team to come into contact with this work would be particularly poor as a result, not to mention their competing HEIF product.
Firefox is by Mozilla, and the browser team ships code under MPL2 (afaik) which permits dual-licensing with GPL2 - but not, as far as I can work out personally, either variant of GPLv3; is MPL2 permissible to dual-license with LGPLv3, or would they be required not to implement an encoder due to incompatibility? (Mozilla seems invested in the AV1 codec, so it’s safe to assume they would be interested in a lossless frame encoder with higher efficiency than lossy options.)
Chromium seems to accept any mix of BSD, (L)GPLv2, and (L)GPLv3 at a brief glance at their codebase, which is quite surprising. (I wonder if shipping Chrome Browser knowingly includes libxz under the GPLv3 terms. If so, that ought to have certain useful outcomes for forcing their hand on Widevine.)
None of these questions would be of any relevance with a less restrictive license, whether BSD or CC-BY or even GPLv2.
I don't think I agree; there are plenty of video and audio formats that exist that were lossless that had traction in the archival and library worlds. Sure, that's not nearly as big of an audience as something like YouTube or Instagram, but it's not nothing.
I could totally see a universe where something like FLIF becoming a de-facto standard in image archiving, particularly for extremely large images. 33% smaller than PNG is a measurably savings in image archiving.
I forgot to mention, there are plenty of non-archival formats that get traction even with incomplete browser support. The MKV container format is only partially supported in browsers (with WebM), but it's still a popular format for any kind of home video.
EDIT: Their reference JS polyfill implementation is LGPLv3 as well, which may further harm adoption.