License change proposition.

Ryan C. Gordon icculus at
Mon Jun 9 06:50:07 EDT 2003

I like to be helpful when people ask me questions about PhysicsFS. I may not
always have an immediate solution, but I hate telling people "that can't be
done at all".

There is one problem that comes up a lot at which I just have to shrug my
shoulders, and that's distribution.

PhysicsFS, being LGPL'd, can not be statically linked to a closed-source
program. Generally this is not an obstacle so much as an annoyance for the
application developer, since they need to ship a shared library and do some
other legal tapdancing (hey, _someone_ will be a pain and demand a copy of the
physfs source tree by postal mail someday!). End result: developers unhappily
put up with distribution issues and possible bug reports, or they do without.

There are places where this annoyance can be a showstopper, though. For
example, I was contacted about a year ago by a game shop that wanted to use
PhysicsFS in a PlayStation 2 title, since the PhysicsFS API combined with
its efficient zipfile archiver is _very_ appealing in light of the PSX2's
awful native filesystem limitations.

How does one ship an LGPL'd library in a console game? End users can't relink
the bugger, after all. Furthermore, their legal department had a fit when they
heard about the "viral" nature of the license when statically linking it...
there is no such thing as "dynamic" linking on a PlayStation 2.

Now, here's the lesson for any future project maintainers: either don't accept
patches, or make sure you own the copyright on _all_ the code before accepting
it. I have poured years of effort into PhysicsFS, but I don't own all the code,
so I couldn't just grant a license exemption to this console developer. End
result: they did without.

I don't like my own hands being tied by my own license. That really doesn't
seem fair to me.

So for these reasons, I've decided to switch PhysicsFS to the zlib license.
The end result of this is that there will be no confusion as to how you can
use the library ("any way you like") and how you can distribute it ("any way
you like"). The only significant loss is that contributers are no longer
legally obligated to give back source changes, but I'm confident that
developers will if it's generally useful and relevant to the public. At least,
I don't think we should license the library with the assumption that
programmers must have their hands forced to do the right thing.

For those that aren't aware of the zlib license, here it is. zlib is used in
all sorts of software without you needing to think about it (including
PhysicsFS), and the license is by far the simplest I've ever seen. This is
the text:

   Copyright (c) <year> <copyright holders>

   This software is provided 'as-is', without any express or implied warranty.
   In no event will the authors be held liable for any damages arising from
   the use of this software.

   Permission is granted to anyone to use this software for any purpose,
   including commercial applications, and to alter it and redistribute it
   freely, subject to the following restrictions:

   1. The origin of this software must not be misrepresented; you must not
   claim that you wrote the original software. If you use this software in a
   product, an acknowledgment in the product documentation would be
   appreciated but is not required.

   2. Altered source versions must be plainly marked as such, and must not be
   misrepresented as being the original software.

   3. This notice may not be removed or altered from any source distribution.

That's that.

Here's how this works: I've compiled a list of all contributors to PhysicsFS
and what was contributed. I need from these people a message saying that they
will approve a switch to the zlib license. Nothing fancy, just quote this
email and say something like "I approve of a switch to the zlib license for
code I own in PhysicsFS." You still own the copyright on that bit of code, but
it'll be under the zlib license.

I can't switch the license until all the developers, below, give me permission,
or their code has been replaced or removed.

If you contributed something and I missed you, please let me know. If I don't
hear from you, I'll try to track you down. If I can't track you down, we've
got to remove or replace your code.

For application developers and end users: you use any code up until we switch
under the LGPL. After the switch, you can use the older code under the LGPL
and the new code under the zlib license. You have less restrictions with the
zlib license, so you'll probably want to upgrade.

Please discuss.


 I tried to list everything, but the LGPL says you can cut-and-paste up to ten
 lines of code, so if you fixed a few typos, you might not be listed here. If
 this is a concern, please speak up.

David Hedbor
 Patch to handle situation when CWD is deleted out from under program:

 Patch to make PHYSFS_setSaneConfig() set Write Directory correctly:

 PocketPC patches:

Patrick Stein
 More-portable __PHYSFS_platformTimeslice() for Unix:

 General BSD-ish (but originally for Darwin) CD-ROM detection:

Gregory S. Read
 Lots of Win32 work (need you to sign off on whole file):

 Microsoft .NET bindings (need you to sign off on whole directory tree):

John Hall
 PHYSFS_getLastModTime() API:

Alexander Pipelka
----------------- fixes:

 doOpen() fix:

 Strange $PATH fix:

Edward Rudd
 RPM specfile (need you to sign off on whole file):

Ed Sinjiashvili
 Various Russian translations:

 Ruby bindings (need you to sign off on whole directory tree):

 QPAK archiver (need you to sign off on whole file):

Pedro J. PŽrez
 Spanish translation:

Stepane Peter
 French translation:

Michael Renner
 German translation:

Adam D. Moss
 extras/abs-file.h (need you to sign off on whole file):

 Initial PocketPC port (need you to sign off on whole file):

Eric Wing
 Apple Project Builder build system (need you to sign off on whole dir tree):

 MacOS X Application Bundle workarounds:

Colin Bayer
 Debian package support (need you to sign off on whole directory tree):

Bradley Bell
 HOG archiver:

 MVL archiver:

More information about the physfs mailing list