Consider Creative Common or other OSI approved license.

[redknightlois]

Very interesting work. I would like this kind of technology to succeed, but GPL is way too restrictive (even v3) to be used by for-profit entities. If they don't use it, FLIF will be always considered as niche for GPL only software.

For FLIF to be considered and accepted on say browsers, standard photographic manipulation software, transcoders, etc it needs to be available in a friendlier license.

Keep up the great work.

[Chilinot]

Yes, the license should really be reconsidered. It is a bit too restrictive currently.

[PhiLhoSoft]

+1 It prevents closed source freewares like IrfanView to even display a FLIF image. Too bad as the format is promising. I would vote for a libpng / zlib type license (roughly MIT / BSD like), or at least a LGPL license (allowing to use the library in a DLL / SO / etc. format).

[Chilinot]

Well, i just found this post about the license issue: https://boards.openpandora.org/topic/18485-free-lossless-image-format-flif/?page=3#comment-399211

[redknightlois]

@PhiLhoSoft as mentioned by some there are platforms where such thing as dynamic linking does not exist (iOS for example).

[redsteakraw]

The main problem I have with GPLv3 on a license for a library like this is that it causes licensing problems for other FOSS projects. This would mean you have to license your project under GPLv3 which might not be doable for projects. GPLv3 is not compatible with AGPLv3 and GPLv2 which means even if you are using a copy-left license and care about software freedom you still may not be able to use this. I don't care about proprietary systems, I care about free software projects and the licensing is problematic.

I will give an example, let's say you are using this in a web imaging processing software you are GPLv3 and all is good. Then someone takes your code-base hosts their own service which runs on their internal server and forks the code internally. Since they are running their modified version on their server and the users aren't running the code it doesn't count as distribution and the copyleft mechanisms in GPLv3 don't come into effect. So you try to license your codebase under AGPL and get the support of every developer, but you can't because this library is GPLv3 and is incompatible with the AGPL.

As you can see this can hinder software freedom, and becomes a burden rather than an asset licensing wise. This software should remain free, while allowing FOSS projects to use it worry free. The license that accomplishes this is LGPLv3 which would allow the GPLv2 and AGPL projects that care about software freedom to make use of it, while ensuring the code base is and remains FOSS and isn't co-opted by proprietary forks like BSD licenses allow.

@jonsneyers I hope you agree and see how the current license may be problematic for other FOSS projects and hinder adoption by projects that truly care about software freedom. Software freedom is important and I applaud you for choosing a FOSS license but IMHO the community may be able to widely use it if it was LGPLv3.

[orlp]

@jonsneyers

Considering you made this remark on the forums:

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.

Keep in mind that this prevents you from accepting pull requests without written and signed copyright disclaimers. If you accept pull requests you must track down every single contributor and ask them to also contribute their pull request under a different license if you choose to switch.

[Unrepentant-Atheist]

More discussion https://www.reddit.com/r/opensource/comments/3n6k6n/flif_free_lossless_image_format_gplv3_and_better/

[redsteakraw]

The FSF has weighed in on this issue before this is from their guidelines

Libraries

For libraries, we distinguish three kind of cases.

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.

For all other libraries, we recommend some kind of copyleft. If developers are already using an established alternative library released under a nonfree license or a lax pushover license, then we recommend using the GNU Lesser General Public License (LGPL).

Unlike the first case, where the library implements an ethically superior standard, here adoption for its own sake will not accomplish any special objective goal, so there's no reason to avoid copyleft entirely. However, if you require developers who use your library to release their whole programs under copyleft, they'll simply use one of the alternatives available, and that won't advance our cause either. The Lesser GPL was designed to fill the middle ground between these cases, allowing proprietary software developers to use the covered library, but providing a weak copyleft that gives users freedom regarding the library code itself.

For libraries that provide specialized facilities, and which do not face entrenched noncopylefted or nonfree competition, we recommend using the plain GNU GPL. For the reasons why, read “Why you shouldn't use the Lesser GPL for your next library”.

This does not fall into the latter category as it has multiple entrnched noncopylefted non free competition.

[Lord-Nightmare]

See johnsneyers' comment at https://news.ycombinator.com/item?id=10320316 which explains his reasoning behind the current license choice.

[ghost]

Lesser GPL 3 is good choice in my opinion.

[Lord-Nightmare]

LGPLv3 unfortunately is still incompatible with many of the projects which would use the image format, such as imagemagick, which is Apache 2.0.

I assume that once the file format is finalized, either the author (or someone else) will write or release a BSD/MIT or Apache version of the library.

[btegs]

Why wasn't this under a BSD style license like Vorbis and Opus to get broadest support? Having it under the GPL means that no major vendors will implement it as the GPL license will force the other code to be GPL. This means you won't see it in Chrome, Internet Explorer/Edge, and Safari. Mozilla may have it as Firefox is under the GPL friendly Mozilla Public License.

So if you want this copyleft, why not have something like version 2.0 of the Mozilla Public License? It will allow each file to be copyleft and it is self contained without affecting other code.

[DagAgren]

As long as this remains GPL or even LGPL, it is pretty much dead on arrival. I don't think there exists a single popular file format with a GPL reference implementation.

[drewcrawford]

I'm going to go against the grain here.

Let's be honest, this is always going to be a niche format. OpenJPEG is clearly better than JPEG and has a BSD implementation, yet Firefox says WONTFIX. WebP is clearly better than GIF, but Safari won't support that either. Mass usage is not even correlated with technical superiority, let alone license permissivity (VP8 in Safari anyone? Ogg/vorbis?) It is not the license that precludes wide adoption, it is that the existing formats are good enough for most.

It is precisely in those cases where "existing formats are not good enough" that this will gain adoption, and in those cases it does not really matter what the license is, because there is no other game in town. You either accept the license terms or else you can't solve your problem at all.

In fairness, there are some proprietary folks who would rather not solve the problem at all than release their code. At times that person has been me. IMO Jon would be wise to offer a commercial licensing option in that case, since many people argue in this thread, it is apparently important to "get broadest support".

[Lord-Nightmare]

I'm guessing it is GPL3 because this 'hit mainstream' before the format was actually finished/finalized. I'm really not sure, personally BSD makes the most sense to me.

[redsteakraw]

@DagAgren FLAC has GPL tools and a BSD decoder. It also is the defacto standard for lossless audio.

[kozross]

Everyone here who speaks against the GPL is a corporate ass-licker and doesn't deserve to be listened to. Keep your software strongly-copylefted please - I believe that the only way we can change things is to stick by our principles. If it's good enough, corps will bend - they've done so before.

[Kyle-Falconer]

@kozross you're really delusional if you think corporations will change their policies just to adopt some software, particularly if that software requires them to change the license of their own software in order to use it.

Apple, Google, IBM, and many many other companies all will not use GPL code, and for very good reason. If you (or a company) authors software, they should be able to choose how they license it. Such a restrictive license like GPL does nothing but hinder adoption.

More discussion about this topic on /.

[DagAgren]

@redsteakraw Exactly. A BSD decoder. Without it, it would never have taken off.

[Uristqwerty]

@kozross GPL also impedes small personal projects, because now the person using the code has to understand the GPL, understand how it impacts their project, and understand what limitations and requirements it imposes upon them.

Not much of a problem for anyone who already interacts with the GPL a lot, or anyone who would disregard the license anyway, but it still creates a barrier of legalese, increasing the cost to use the code for many individuals.

Or have you not fully read and fully understood the GPL, either? Not a human-friendly summary, but the actual document?

[herrbischoff]

The strongest argument I fully support was made by @orlp:

Keep in mind that this prevents you from accepting pull requests without written and signed copyright disclaimers. If you accept pull requests you must track down every single contributor and ask them to also contribute their pull request under a different license if you choose to switch.

This simply means that if even a single contributor is unwilling to let you change the license later on, your license change will fail. Think about some core change that gets built upon by others. Now the original contributor rejects relicensing the code as, for example, MIT. Now you'd have to fiddle that code out of there, reimplement it to be compatible with all the changes that came after it and hope it's still working and stable. Do you really want to do all this work? I believe this uncertainty repels contributors as well as developers looking to use the format in their projects. That's why I release everything I do release MIT- or CC-licensed aka free culture licenses.

It's kind of commendable that you want to keep this software in the copyleft spectrum but the issues with doing that are widely known, especially with file formats. GPL-licensed, this format will see absolutely zero public adoption besides some Linux distributions. In the end GPL hurts adoption more than it helps the free software cause.

Please reconsider.

[onpon4]

Considering that this format is competing with existing libre formats, I see no reason why it should be a goal to put it under permissive terms. Supposing the GPLv3+ license remains, it would mean less adoption. But so what? PNG and JPEG are perfectly fine, and they're already widely adopted. FLIF would just be a nice bonus for libre programs. I could see myself using this for games I develop, for example.

One additional possibility would be to provide a permissively-licensed decoder, but keep any encoders under the GNU GPL. This would have the effect of making creation of FLIF files exclusive to libre software, while allowing proprietary programs to read them still. So for example, it could enable the GIMP to have that as a subtle advantage over Photoshop, at least until Adobe decides to develop its own FLIF encoder.

On a side note, I'm seeing some people claiming that RMS would never support the use of the GPL here, and to be perfectly frank, that is nonsense. RMS encouraged permissive licenses for formats competing with patented or secret formats that were in common use (like MP3). Adoption of Ogg was important only because MP3 is patented, and adoption of VP9 or Daala or some other next-gen libre video format is important only because h.264 and h.265 are patented. In the case of images, the most commonly-used formats are non-patented and non-secret. There is not an urgent need to replace them.

[vyp]

Or have you not fully read and fully understood the GPL, either? Not a human-friendly summary, but the actual document?

@Uristqwerty I know you are not asking me, but I just have to say, I don't understand this "too long to read" argument. The GPL cannot be as short as an Expat license or similar because it's not lax, it has restrictions pertaining to copyleft, and it has to define these restrictions. And as with any legal text, this has to be exact and non-vague, meaning it can become quite verbose.

As for the actual length of it, yes it's long, but it's not impossible to read long. Nevertheless, yes I agree with you that understanding it all is a different matter unless you're a lawyer. For that though I recommend https://www.gnu.org/copyleft/ and https://copyleft.org/ for a more legal perspective.

[drewcrawford]

There is a lot of FUD in this thread about what "they" will do, for various values of "they" (proprietary companies, web browsers, users, contributors, etc.) There are many other forums where it is more appropriate to speculate generally about other people and what they may or may not do. There are other places where it is appropriate to take up for discussion the length of the GPL, the personal views of RMS, and so on.

IMO this discussion should be restricted to that information which may actually help @jonsneyers make a decision about this particular project, and how the license choice would actually impact users and contributors who are real and substantial rather than hypothetical. I would kindly suggest that we keep discussion to those points, as I (and I'm sure many others who have been around the block before) have better things to do than wander into the weeds about the merits of copyleft for the billionth time.

Now staying on topic, I have one proprietary project that is real and substantial and could benefit from this. However FLIF would be more of a "nice to have" than of real benefit, we survive fine on PNG/JPEG. GPL is too strong, but for LGPL/MPL we might make this configurable for those users who want a performance edge. We would consider commercial licensing if available and it made sense (but it probably doesn't, for a "nice to have" improvement). We are very unlikely to reimplement this, as there's plenty of lower-hanging performance fruit than the image format. If a BSD/MIT implementation did come along however, we would probably use it.

[vyp]

@redknightlois The gpl is osi approved.

[Lord-Nightmare]

Given the list of licenses in CONTIBUTING.md and the CLI agreement, I think most external users would be fine with Apache 2.0.

[Calinou]

Given the list of licenses in CONTIBUTING.md and the CLI agreement, I think most external users would be fine with Apache 2.0.

Apache 2.0 is not compatible with GPLv2 or LGPLv2! It would mean many programs would have trouble using it. Moreover, it is a quite complicated license for what it really does.

This is a free software license, compatible with version 3 of the GNU GPL.

Please note that this license is not compatible with GPL version 2, because it has some requirements that are not in that GPL version. These include certain patent termination and indemnification provisions. The patent termination provision is a good thing, which is why we recommend the Apache 2.0 license for substantial programs over other lax permissive licenses. —Various Licenses and Comments about Them

 

There is not an urgent need to replace them.

My JPEG textures would disagree. I would really like lossless to take off for things like high-resolution textures.

Now staying on topic, I have one proprietary project that is real and substantial and could benefit from this.

How about liberating it? :suspect:

[onpon4]

All a GPLv2 program using an Apache 2.0-licensed program needs to do is include a note permitting linking with that program. GPLv2 is an old license, anyway, so I don't think that should be a particular concern.

[FLIF-hub]

I suppose I can close this one now. Further license discussion can happen in #14 if needed.