hmn said:
[*]Source code
Allows usage of the lib in projects that cannot use the library binary, maybe because they
already link against a different version of SDL... it could also be possible to turn SDL support off
at compile time, if it is not needed/wanted in a project.
[*]Proper open source license (GNU compatible)
Otherwise it will not be legal to use the lib with a lot of stuff out there.
[/list]
Licensing problems are a lot of pain, and opening everything does not necessarily solve the problem.
Linking to an external (i.e. dynamic) library does not necessarily violate the GPL / LGPL. With GPL it's still an unanswered question with open-source lawyers arguing both sides. With LGPL, that was the entire purpose of the licence. Most LGPL software (like SDL) and other open-source code recognises this. It's fine for me to supply a binary that is linked against SDL, SDL_mixer, SDL_gfx, etc. so long as the parts of the LIBRARIES that I link to have source-code available - i.e. if I link to a dynamic SDL library (e.g. DLL or .so) and distribute that, then the code to THAT library is still subject to the license and any source-code-visibility-restrictions, but the code that loads the SDL library and executes commands from it - i.e. my game - is not (in general).
The bad thing is static linking, which some GP2X apps see as necessary - as soon as you statically link SDL (i.e. build SDL into your binary such that it becomes a whole piece that cannot be separated from your code) then your code needs to be under the same license. I did this myself with STPPC2x because, well, it made licensing simpler when it was starting to get out of hand (STPPC2x has MIT, BSD, GPL and LGPL code in it, I believe, and I was as careful as I could be to make sure everything was compatible and legal - it was developed in Cygwin but all distributed binaries are from non-Cygwin dependent code). But a new project of mine, which probably won't be open-source, was developed in MinGW and dynamically loads SDL and some other libraries from separate, external library files and that's fine. If someone wants the source to those particular library files, no problem. You can even have the source to my whole development environment (in theory). But they don't need the source to my program that uses those libraries (in general). It means that everything became a lot easier to manage from a distribution point of view. GPL'ing STPPC2x meant that it was ported to everything from the PSP and NDS to the Wiz/Caanoo because someone took my source and could do something with it. But I had to spend a lot of time checking licenses properly in order to make sure that it was legit. I'm not sure that a lot of programmers do that kind of due-diligence work - I've seen GPL/LGPL code inside GP2X programs that don't have an offer of source, and even some people who wrote ports of STPPC2x never fed their source code changes back.
Lots of programs on Windows work using open-source DLL's (*dynamically* linked *libraries* - the thing we're talking about here) and yet don't subject their main program to the GPL. "Super" (the video convertor) was one last time I looked. The FSF says that dynamic linking isn't allowed, other lawyers disagree (and the FSF are NOT the official source of information here - it's all very much a legal grey area dependent on a court's interpretation, not the FSF. It would be a costly fight to decide which is right and would be one of the defining moments of open-source... nobody has yet done that or knows for sure if it'll be successful. It centers around whether an external DLL is "derivative" of a program that uses it, or a work-alike DLL, and work just the same. LGPL makes things clearer - lots of commercial games use SDL libs and things like that and don't pay for a commercial license.
In this case, it would not be difficult for someone to link against this library with a GPL program, but not include it in the final executable, and supply an external, dynamically-linked file along with the program whose source code was closed. If that file was missing, it would be very simple to run the game but without the "achievements" library loaded at all. Or vice-versa, linking a GPL library from a closed-source application. So long as you don't generate a single binary that has bunched together code with lots of different licenses, you're almost certainly fine.
That's why the library binary is supplied, I guess, because it avoids 99% of the licensing problems - without needing to give away the source code. However, I believe there may be a licensing problem here - if the library can take and act upon an SDL_Surface, it suggests that it was compiled using SDL headers or code. That means it's almost certainly required to be LGPL anyway. Thus, the very act of publishing it here means that the author might have to divulge source code if someone asks. This is why a lot of the open-source licensing stuff is avoided by some programmers.
Licensing is a nightmare. Even if someone opens up their code, the arguments and pitfalls of combining licenses is a pain. Hell, compiling MinGW apps with profiling enabled makes them subject to the GPL - but without, they can even be entirely proprietary or public domain. And it matters what version of the GPL you interpret the licence as being. An external library that programs choose to load if it's present solves 99.9% of the problem for everyone. Whether it's GPL or not, doesn't really make anything any easier.
Whenever I program, I keep a file in the project folder - it says, in my own plain English, what source I've used, what the license means and where I got it from. I even save things in there like "permission" emails from graphics artists, musicians etc. if I ever use their work. It's not unusual for that file to be larger than most of the source code files, even if I state stuff briefly. To me, the GPL is/was a wonderful idea but it's been so corrupted by technical problems, unclear generic wording, and other things that it's become a BIGGER pain to use GPL stuff than to just use other licenses or public domain stuff. If you GPL this library, for instance, then games-authors might be obligated to GPL their games. If you LGPL it, then other programmers will be able to use it dynamically but you have to release the source. If those authors link statically and your library is GPL or LGPL, they are in violation. If their game is GPL but they link with your proprietary library, they are STILL in violation. If you just leave it as proprietary, it's up to the individual programmers whether they want to load/bundle it and under what terms, and the onus is on them, not you.
OS licenses are never clear-cut, and rarely solve any licensing problems. Linux uses GPLv2 ONLY (no "or above"), Cygwin has weird GPL dependencies that (although clarified) seem contrary to the licence, MinGW can introduce GPL'd code when you debug if you're not careful, cdrecord tried to mix GPL and an incompatible licence and still nobody's sure what to do about it, GPLv3 doesn't solve anything but a few patent problems - at any point the wording on the licenses could have been written to take account of that stuff much more sensibly (at least for the "or above" users) but hasn't. Open-source licensing is hideously complicated for such a simple thing - "use my code, but don't run off with it or claim it as your own".
The author of this library would probably be massively discouraged now if they wanted to keep source secret - the only real sensible way to avoid legal hassle at all is to LGPL it or remove the "Supply an SDL_Surface" parts, which could cripple its usability. And encouraging static linking would be quite a bad thing either way, but at least the violation would not be the fault of the author of the library, but the person who statically links and distributes.
A lot of games, libraries, etc. on the GP archives are violating some clause of some licensing somewhere, it's just that nobody has bothered to report it. That's not to condone it (I don't, and if I found out my proprietary code had GPL code in it, I'd rip it out immediately and/or publish source and would be INCREDIBLY embarrassed and much more careful in future), but open-sourcing this particular library doesn't actually solve any more legal problems that it creates. I'd encourage the author to remove the SDL Surface functionality, or LGPL the code if possible, but claiming that merely throwing it under some GNU licence would fix things is short-sighted.
Code licences are a minefield. Hell, I have a line for every third-party PNG image, OGG file and piece of code that my latest game uses describing it's origin and licence. When I modify them to suit my game, I have to keep track of where the original came from and what I did to them and what images use what artist's copyrighted works. It's a pain and yet still most programmers do NOT keep track of this stuff. This library is the least of any FSF-fanatic's worries.
