Because it is GPL3, it won't be supported by Google on Android, by Apple probably anywhere, or by Microsoft anywhere.
In other words, it's a lovely idea, but due to a poor choice of license, it won't get any adoption. C.f. Ogg Vorbis, where the license for the specification is public domain, and the license for the libraries are BSD-like.
To quote FSF:
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.[1]
I would suggest that this is a case where widespread use is more important than copyleft.
In the forum thread I linked elsewhere, the author wrote:
"In terms of licenses: GPL is all you get for now. I can always add more liberal licenses later. LGPL for a decoding library, or maybe even MIT? We'll see, I'm not in a hurry."
Wow, starting with an unusable license with the intention to switch to a more practical one later is a weird strategy. I guess that's one way to discourage people from adopting it before it's ready.
(Edit: As I clarified, I meant usable for adoption in other non-GPL projects. But OK, I deserve the downvotes for adding very little, and will think twice before posting such a reply next time)
Starting with a more restrictive one leaves his options open; moving from restrictive to liberal is a lot easier than moving from liberal to restrictive.
Erm, what? If you have ANY contributors other than your core project team going from a restrictive to a more liberal license requires agreement from all of them, as they ALL have copyright somewhere in the project.
The opposite, going from something like MIT or BSD doesn't require ANYONE to be okay with it, the license permits it.
My point was, if he had released his code as MIT/BSD and then wanted to change it to GPL it would be fairly ineffective -- people could still use the old MIT/BSD version in their proprietary products.
If you want to use it commercially without publishing source, just buy a licence from the author. Buying licences isn't exactly uncommon. Or are OS X/iOS/Windows also unusable for you?
> Also commercial "standards" by one party are worthless
Very true, but I can't see how that applies to this project? First, the existence of this repository doesn't preclude proper standardization. Second, the reference implementation is freely licensed, not commercial.
I think it has more to do with maintain control initially.
It is a lot easier to restrict now and liberalise later once more thought has been given to the options, than it is to draw things back in later if you decide you want more control for any reason.
Not really propriety software - as you & bildung said, it's not a problem if you can just buy a license. I meant anyone working on FLOSS software that isn't GPL compatible, which is probably most FLOSS software. MIT, BSD, etc are very popular these days. And image formats are generally intended to be widely-adopted standards used across different applications.
Most "FLOSS" software is GPL. Almost all is GPL compatible.
But even the FSF recommend sometimes using don't-care-about-user-freedom licenses for strategic reasons, for example driving adoption of a new free codec...
Firefox is GPLv3 compatible. It's quite likely that it will support this format - although, if it's the only major browser doing so, it will not be adopted by most web publishers.
I would be very surprised if Firefox added support. They have been very reluctant to include any additional image formats that weren't developed by Mozilla employees. See for example WebP and Jpeg2000.
Their reasons being things like added security risk, lack of demand, lack of support in other browsers, patent risk etc, which all apply just as much to this format.
The Mozilla Public License is GPLv3 compatible. Firefox also contains code that is under different licenses that is not GPLv3 compatible, and thus firefox is not GPLv3 compatible
That's only the implementation, not the image format itself. Unless I am mistaking, you can't apply a software license like GPL to an image format, just patent it.
You're correct. There is no copyright for ideas, and licenses are just a way to "relax" your copyright. Unless it's patented you are free to make your own implementation of the format without any restrictions.
So, the free world can use this library and the proprietary world will have to develop their own if they want to use the format. Proprietary software developers get to piggy back off of tons of free software, and then when someone decides that they don't want to enable that for their particular program/library, people complain about it. It makes no sense.
A while ago I wanted to include a library in some GPLv3 software, but I couldn't because that library was GPL2-only with no "or any later version" clause. And both versions of the GPL are not compatible unless the GPL2 software has this "or any later version" clause.
So even if you stay strictly within the free software universe, even only within in GPL universe, a strong-copyleft license is a bad choice for a library.
I think license depends on your goal. If your goal is to create a web image format.. you need all the browsers to agree to include you. All browsers will not add a GPLv3 image type. Therefore it is dead before it launched.
No, that's backwards. Microsoft and Apple and Google prevent the usage of the GPL/LGPL. Don't blame the GPL for the bad behavior of large corporations that are using their immense power to try to stop copyleft.
You can't link proprietary software with GPL libraries, only with LGPL libraries.
For but Apple it's not even a licensing concern. Apple doesn't have a problem with the GPLv2, but doesn't touch the GPLv3 because of the patent clauses that it contains. The bash in OS X is a version from 2007 because that's the last GPLv2 version of bash. But Apple has no problem including git because that's also GPLv2 and not v3.
FTA:
"FLIF is a work in progress. The format is not finalized yet. Any small or large change in the algorithm will most likely mean that FLIF files encoded with an older version will no longer be correctly decoded by a newer version. Keep this in mind."
Perhaps the MANIAC/CABAC decoding or encoding is computationally more intensive compared to the others? Concerning lack of support, just like with the BPG decoder you could generate the Javascript through Emscripten so any javaszcript enabled browser can view them. Personally an even more efficient lossy image compressor would be great (getting my avatar down to 1K and still sharp). When using diagrams or text the mozjpeg artifact eraser is adequate.
