Hacker News Reader

Comment by floatingatoll | Hacker News Reader

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.

View on HN

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.

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?

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

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.

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.

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.

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

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

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

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.

> LGPL is incompatible with signed executables

Do you have a source for that ?

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

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.

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?

> Could you please provide supporting evidence for your view that is a consensus?

Consensus is what is admitted by most actors, specially including the main interested actor: The FSF and the GNU project. And I do not remember reading any communication of the FSF or the GNU project saying it is forbidden.

Currently the license text is very explicit about what you can do and not do if you link statically.

> 0) Convey the Minimal Corresponding Source under the terms of this License, and the Corresponding Application Code in a form suitable for, and under terms that permit, the user to recombine or relink the Application with a modified version of the Linked Version to produce a modified Combined Work, in the manner specified by section 6 of the GNU GPL for conveying Corresponding Source.

Which means: You have to provide a way for your user to recompile statically their application with a new version of the library. Meaning, you have to provide a tarball with your object.o files if someone ask for it.

It is even documented explicitly by the FSF:

https://softwareengineering.stackexchange.com/questions/3127...

https://www.gnu.org/licenses/gpl-faq.en.html#LGPLStaticVsDyn...

So, for macOS — where static executables aren't viable — you would need to ship all pre-linking components and then let the user assemble them.

You could ship those elements in a signed DMG, but it would be up to the user to assemble them, and so the user would not be able to codesign them under your developer ID.

Since they would not be able to compile and run the app as your developer ID — it would have to be theirs, since they're the ones linking it — the app won't have access to any ID-linked features such as iCloud syncing, Apple push notifications services, and so forth.

So that would imply that it's outright impossible to use this "static linking" bypass on MacOS when code signing is enabled, since you can't falsify the original signature's private key in order to sign the executable and gain access to signature-enforced platform capabilities.

I guess it would probably work fine for Linux folks, and you could always sign it with your own ID, but this certainly is not "compatible with signed executables" — to answer the original question asked upthread.

Do signed executables fail to load unsigned DLLs?

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

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?

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.

Reply on news.ycombinator.com