Hacker Read top | best | new | newcomments | leaders | about | bookmarklet login

Wow! Higher compression than any other format, full transparency support, progressive/partial loading AND animations?! I can't wait for this to get widespread adoption!

Github repo here btw: https://github.com/jonsneyers/FLIF



view as:

GPLv3 will be a hard sell...

In fact, it makes it impossible to use in practice. None of the major browsers are GPLv3.

The GPL is compatible with BSD, MPL, and MIT licenses that Firefox / Chromium use.

The problem is more that Firefox / Chrome ship proprietary bits like the DRM modules that would violate the linking GPL coverage of flif. And that Chrome is proprietary.

Its going to need to be relicensed LGPL to be included.


> The GPL is compatible with BSD, MPL, and MIT licenses that Firefox / Chromium use.

Yes, it is compatible, the other way around. You can take BSD, MPL, MIT code and adopt it into a GPL project, not the other way around.

EDIT: Even LGPL won't work here as it will prevent use on Windows Phone, iOS and Android.


If Apple's attributions are correct (1), there is LGPL software on iOS, for example libiconv, and even GPL software (libgcc, libstdc++), but those have linking exceptions. WebKit also is partially LGPL.

Possibly not coincidental, the latest LGPL version I could find in the 'legal' section is 2.1.

(1) they may be overly cautious, given that they mention the L4 kernel, lua, and Tiny Scheme.


bzzt.

LGPL code is everywhere in Android and iOS. There are numerous apps built on GStreamer for both platforms, which is LGPL.

I wouldn't be surprised if Microsoft pulled the pig-headed move though.


> LGPL code is everywhere in Android and iOS.

You're not going to find LGPLv2.1 or LGPLv3 anywhere in them, however. Starting with LGPLv2.1 you are required to allow the end-user to replace a compiled binary you provided of the LPGL'ed component with their own, something that obviously cannot be guaranteed on any of the mobile platforms I listed.

I suppose I should have clarified the version, but it's important to note that the FSF has tried to pull the tivoization card with more than just v3 of their licenses.


Firefox doesn't actually ship anything proprietary. DRM module is an optional plugin from Adobe.

The Mozilla Public License used by Firefox is compatible with the GPL.

Also, if it's a file format and not just a particular library, shouldn't it be possible to reimplement support for it under different licenses on different browsers?


If the only spec is the code, that's going to be prohibitively difficult. There's a warning that the format isn't complete either, and you can expect breaking changes.

I suppose (hope) that once they finalise the format, we'll have tools released with free, unencumbered licenses.

you don't have to use the code, you can (and probably want to) implement the code yourself.

Why do you really want to duplicate work and write, test, debug, maintain... a FLIF decoder yourself?

Also, I'm not sure how far do you have to deviate from the original code to not be covered by its license.


Technically, I believe the answer is 100%. If you're using the original code as a starting point or a reference for your code, then you're basically creating a derivative work.

Correct, you have to do a clean room implementation. You either start from a public standard, or you need two separate teams. One team is allowed to look at the existing code and make a detailed description of what it does, but not write any new code, and the other team can read the descriptions from the first team and write the new code, but they can't ever look at the old code.

This only works to avoid copyright infringement. Patent infringement cannot be avoided in this fashion.


And that, boys and girls, is how we got the PC clones. Thanks to Compaq no less. Could not happen today though, as back then IBM could not patent the BIOS chip.

You can copy how something works, copyright doesn't protect that, patents protect that. If the form of it is necessary for how the thing works then it's not an artistic expression and so you can copy that directly. Generally speaking there are not interoperability exclusions though so if the choice isn't technically essential you can't copy.

> Why do you really want to duplicate work and write, test, debug, maintain... a FLIF decoder yourself?

Because multiple implementations are useful.


Very, very hard. I don't see why they didn't use LGPL, as GPL will greatly increase the barrier to adoption.

You see how unsupported WebP is at the moment. Simply having a better compression ratio isn't gonna cut it.


The real barrier to adoption is, for the time being, older browsers, anyway. Want to lose 20% of your potential market via IE in favor of some improved image compression? =\

True enough... though there are a lot of other ways this can/could make it in the interim... much like webp through various optimizing/ha proxies. I to think GPLv3 will hinder peopler even trying to look at or support the format though. There are some legal minefields that many won't cross when it comes to copyleft... even if they wanted to many are in jobs that wouldn't allow it.

Jon Sneyers is a known advocate of Free Software, I am actually glad he acts on his beliefs.

Based on how he's acted in the past, I think even Stallman would've advocated something like the MIT or BSD license for something like this -- having a patent-unencumbered alternative to formats like JPEG 2000 being used seems to be more important to a lot of Free Software people. In other words, the advantage of having widely-used file formats that are accessible to free software programs are considered greater than the benefits of having software become libre in order to use GPL'd file format libraries. Stallman defended the use of a non-copyleft license for Ogg/Vorbis on those grounds:

https://lwn.net/2001/0301/a/rms-ov-license.php3


> even Stallman would've advocated something like the MIT or BSD license for something like this

Almost, Stallman (well, the FSF) advocates Apache 2:

  Some libraries implement free standards that are competing against restricted
  standards, such as Ogg Vorbis (which competes against MP3 audio) and WebM
  (which competes against MPEG-4 video). For these projects, widespread use of
  the code is vital for advancing the cause of free software, and does more
  good than a copyleft on the project's code would do.

  In these special situations, we recommend the Apache License 2.0.
Source: https://www.gnu.org/licenses/license-recommendations.html

If it gets popular, I'm sure decoders with more permissive licenses will show up.

It is pretty hard to become popular with no software support.

Yes, but let's give this a little time. If this was going to be another example of 'the code is the spec' it wouldn't go far anyway. That's a n00b mistake, and I don't think these guys are n00bs.

If this is worth using (and it's the first thing in several years that made me sit up and say 'ooOOoo') it won't get lost. There will be a way for the world to use it.


Actually, now that I think about it a bit, maybe not. If your only interface to this is feeding it a compressed file and getting back a bitmap, then you haven't derived from it. You enter a certain legal gray zone, but you should be okay loading it as a dll.

That's just the first implementation. Anyone can reimplement it. And as noted elsewhere in the thread, it won't continue to GPLv3 after things settle down.

I didn't see the part about full transparency. I was looking. Where do you see it?

Legal | privacy