[floatingatoll]

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.

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

[adev_]

> With the reference encoder licensed under LGPLv3, I doubt any browser team will be able to incorporate this work into their product.

I'm gonna make enemies....

That's FUD and BSD bullshit.

LGPL is not GPL. You can link what the fuck you want to a LGPL library included your proprietary code as long as you link dynamically.

Gtk+ uses LGPL, GLib, uses LGPL, GNOME use LGPL, Qt uses LGPL, Cairo uses LGPL and millions of applications link into these ones without problems.

I'm not aware of any case in history where a company got attacked, or frightened to use a LGPL library in their codebase.

It would be good to stop the FUD excepted if you need to feed your lawyer.

[DagAgren]

LGPL is incompatible with signed executables, which locks it out of anything distributed through an app store, which is a lot of software these days.

[adev_]

> LGPL is incompatible with signed executables

Do you have a source for that ?

[floatingatoll]

HN seems to have discussed this back in 2012: https://news.ycombinator.com/item?id=4789784

[adev_]

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.

[floatingatoll]

Do you have a source for that?

Could you please provide supporting evidence for your view that is a consensus? Where is the documentation explaining your “static link” proposal and why it’s been endorsed by lawyers as a permitted approach? What was the response from the GPL team when they were asked to comment on this circumvention of their license? Will they be patching GPLv3 to correct it?

[CamperBob2]

Do signed executables fail to load unsigned DLLs?

[littlestymaar]

You're confusing the encoder and decoder: a browser only needs an encoder and FLIF provides a Apache-licenced one.

[yarrel]

It's FUD time!

The LGPL is hardly "restrictive". If you aren't modifying the code, and for a codec if you are I have questions, then you've nothing to worry about.

Regarding license compatibility, which actually existing browser are you worried about the licensing terms of?

[floatingatoll]

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.