SDL_image license


I am developing SDL application on Linux PC
I read IMG_png.c and found following lines

#if !(defined(__APPLE__) || defined(SDL_IMAGE_USE_WIC_BACKEND)) || defined(SDL_IMAGE_USE_COMMON_BACKEND)

#ifdef LOAD_PNG

#define USE_LIBPNG

        File: SDL_png.c
     Purpose: A PNG loader and saver for the SDL library
  Created by: Philippe Lavoie          (2 November 1998)
 Modified by:
 Copyright notice:
          Copyright (C) 1998 Philippe Lavoie
          This library is free software; you can redistribute it and/or
          modify it under the terms of the GNU Library General Public
          License as published by the Free Software Foundation; either
          version 2 of the License, or (at your option) any later version.
          This library is distributed in the hope that it will be useful,
          but WITHOUT ANY WARRANTY; without even the implied warranty of
          Library General Public License for more details.
          You should have received a copy of the GNU Library General Public
          License along with this library; if not, write to the Free
          Software Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
    Comments: The load and save routine are basically the ones you can find
             in the example.c file from the libpng distribution.
    5/17/99 - Modified to use the new SDL data sources - Sam Lantinga

This means IMG_pnd.c is LGPLv2 and SDL_image itself is LGPLv2
Is my understanding correct?


(we spoke by email, but I’ll post here for the public to see this, too…)

This license header was from before SDL_image switch to the zlib license, but it’s not clear to us if this contributor gave permission to switch from the LGPL. For caution’s sake, I’ve removed this code from SDL_image as of tonight:

In this same commit, I removed libpng, zlib, and miniz from SDL_image as well. PNG loading and saving is now done through lodepng, which is zlib-licensed and doesn’t require any external dependencies.

This code is all new, which resolves any licensing concerns, but it also needs testing. If you have a project that uses SDL_image, I’d encourage you to grab the latest in revision control, build it and use it with your project. Please report problems building or using it to me, either in a reply to this post or in a bug report at



You forgot to add the lodepng files to the repository.

Doh, fixed! Sorry about that!


what a sticky situation.

I’m sure loadepng is a fine library. However, looking at the bug tracker and other trackers reports (and CVE reports) for loadepng, it does not look like it never needs updating again. Most distros of SDL_image seem to ship an updated libpng when it has had issues before new SDL_image releases have been done. I’d be surprised if there are not other compatibility and security issues on top of them. It reminds me of the ImageIO situation on MacOS - where some versions of SDL_image used it and those ones had lots of hard to debug compatibility issues.

What sort of testing have you done with loadepng? There’s a few png related unittests in pygame you could run against it. But not at all exhaustive.

Have you asked for their consent? Probably, with an apology they won’t mind relicensing. Without saying anything to them now, the reaction could be worse in the future perhaps. By sorting this out in SDL_image, all the downstream packagers and distros won’t need to deal with the removal themselves in older versions.

I’m not sure you can look at the SDL_png.c, implement parts you take out, remove someone’s credits and copyright and then re-license it. I’m not a lawyer, but pretty sure that’s not ok legally. It’s also not ‘cool’ imho.

To me, it seems there’s no benefit to rushing this, and to instead first ask the original author for their consent to re-license it.


Replacing code that is incompatible with your license is standard practice, whether you are a single maintainer or the Free Software Foundation. It would be disrespectful to keep using the code in a way that violates the license.

In any case, I’m not required to maintain someone else’s code that hasn’t been touched since the 1990’s in case it hurts their feelings not to.

Anyhow, we didn’t relicense it or clean-room reimplement it (which would be “uncool” imho) but rather went in a different direction from scratch, which I’ve been wanting to do even if this issue hadn’t made it urgent to do so.

Was sort of expecting a response like this. I’ll drop out of the conversation here.

(Fwiw, we don’t know how to contact the original developer. He had a University of Ottawa e-mail address in 1998 and published research papers there about 3D graphics until the mid-2000s, but vanished after. There’s another person with the same name at the University of Toronto, but the subject matter is different and I’m not confident it’s him. We did do some research on the matter first.)


But what about performance?

I did a google search, and found someone who went to that university at that time with that name doing that type of work. I’ll let you know if they respond.

In terms of performance, LodePNG’s API has hooks to add your own zlib decompress/compress functions. In my code which uses LodePNG I make it use zlib’s own APIs for that, which is quite fast compared to what LodePNG provides on its own.

That said, both the linked benchmarks and my own tests are several years old, and it’s possible LodePNG’s default performance has improved significantly since then.

He got in touch with us and approved a license change. Nice work. :slight_smile:

I’m asking Sam if he has any strong opinions about keeping one version or the other of IMG_png. I’d personally rather not keep both, but we’ll see what happens next.


1 Like

Since we have definite permission to relicense the original code, we decided to back out the lodepng code, so we’re back exactly where we started now, except with the licensing concerns resolved, which is probably the best outcome.

If anyone wants the lodepng version, it can be extracted from revision control.

(Thanks to Philippe for his permission, and Rene for the detective work!)

1 Like