Hacker News Reader

Comment by spullara | Hacker News Reader

One of the least interesting parts of this is that it is GPL. Someone should reimplement it with a BSD license so it can be used more widely. AFAIK & IANAL, but I don't think you could integrate this with FF, Chrome, Safari or IE.

View on HN

No kidding. If you want an image format to become widely adopted and standardized, GPLing the code is a pretty bad idea.

Not just an image format, everything you want to become widely adopted and standardized should refrain from using the GPL, even the FSF[1] recommends using the Apache License in this specific case.

  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.

[1] https://www.gnu.org/licenses/license-recommendations.html

Note that the Apache License isn't compatible with GPLv2. If you don't make use of any patents use BSD/MIT/ISC instead.

Sadly there isn't a real alternative permissive license with a patent clause. There is a license called COIL[1], but it hasn't seen much adoption yet.

[1] http://coil.apotheon.org/

Nothing that a dual license GPL/APL wouldn't solve.

I think it's great to have a free software solution which wholly eclipses the competition. It's an incentive to use free software (use free software and get the best image codec in the world).

Yes, but the technology of "storing images" is never going to become the domain of free software. It's a little late for that.

If you're trying to drive widespread adoption of a competing file format, then don't GPL the only code that implements it. Make a brain-dead reference implementation with a license as unencumbered as you can stand. (Then code up an elegant implementation and GPL that.)

He intends to make the spec public as well as to switch to a more permissive license once the format has stabilized, so I wouldn't be too concerned yet.

It is an issue on the GitHub Project:

https://github.com/jonsneyers/FLIF/issues/3

The title incorrectly suggests Creative Commons (which is inappropriate for code), but the discussion does suggest better alternatives.

I think it's the most interesting because it immediately turned me off to the project. Releasing this only as GPL basically means it will NEVER be adopted en masse :-(

Seems like the mistake the author is making is announcing something as a "product" when it's really still a "project."

In principle, using the GPL license for the reference code is OK if his intent is to encourage other people to build more refined, practical, and performant implementations. But the real problem with his choice of license is that a lot of people can't even look at the code for fear of tainting themselves legally. Given that there is no desperate market demand for a better-PNG-than-PNG, it wasn't a good idea to handicap the proposed format by saddling it with various restrictions and legal minefields.

If the reference code is strictly of proof-of-concept quality, which it sounds like it is, then there was no reason not to use a more permissive license.

People should not be reading HN or any news at all if they fear committing patent or copyright infringement from just looking at code. You lock those people into a bunker without internet and just a computer to do the work, and after we call all be safe that it was legal.

I think the right avenue is to keep the license GPL but provide a permissive as-is use license. The idea is that you want people making improvements to the algorithm to contribute those back for the public's benefit rather than charging people for their "upgraded" version. A separate unmodified-use license could be much more permissive in the use of algorithm as-is for compressing and decompressing images.

That's effectively LGPL.. even then, though it would still be problematic for embedding and hold back adoption in browsers and various platforms (game engines, etc).

Realistically a basic rendering and conversion implementation should be at least Apache 2, or something even more permissive (MIT/BSD/ISC). It was my first thought/comment when I saw the GPLv3 notice... They should switch the license quickly if they want to see adoption/support. Getting a free standard in place is more important than using a copyleft license.

Or at least LGPL, but that is still a hassle for embedded use. GPL may prevent some from trying to embrace/extend/extinguish, but you get around that by writing a spec and clean room code from the spec. Right?

I understand the sentiment behind wanting to GPL projects and I would myself if it didn't lower even further the already infinitesimal possibility of someone reusing my code.

Reply on news.ycombinator.com