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
Revision:
Created by: Philippe Lavoie (2 November 1998)
lavoie@zeus.genie.uottawa.ca
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
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
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.
Changes:
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 https://bugzilla.libsdl.org/
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.
(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.)
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.
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.
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!)
