[yellowapple]

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.

[floatingatoll]

Evaluating the efficacy of the new image codec is not possible using only a decoder.

I was unable to find an APL2 JS polyfill decoder. Does one exist?

[sjwright]

How would the evaluation of any codec be hampered by any open source license?

[Polylactic_acid]

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.

[floatingatoll]

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.

[sjwright]

Your question makes no sense. If a license is so restrictive to you that you can’t deploy it to testers, why would you be wanting to evaluate it in the first place?

If you’re not distributing the result to other people, literally nothing you described matters at all.

As for integrating ideas, as long as you don’t copy actual lines of code, simply learning ideas and techniques from any OSS doesn’t cause license infection.

That’s not evaluating a codec though, is it? You’ve gone far beyond the scope of this thread.

[yellowapple]

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.

[gunn]

I'd definitely hope browsers could encode them for example to allow canvas.toDataURL("image/flif")

[yellowapple]

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