Hi all,

I am currently working on integrating PhysicsFS into my game. The core of this software itself is licensed on the zlib license, which is permissive enough to use in closed source applications.

However, to use the 7-zip archive format with it, it needs to be linked against the LZMA SDK which appears to be LGPL licensed. There is no provision in any way in PhysicsFS to make the LZMA SDK be dynamically linked against the PhysicsFS library.

Therefore i appear to be at a loss as to if i can use 7-zip format at all, as i can't allow dynamic linking due to the design of PhysicsFS, and i can't do static linking if i use it due to the LGPL license of 7-zip.

My only choice appears to be to use only the zip format instead, which is also licensed with the zlib license. This would save me having to provide source for a modified version of PhysicsFS along with my game, or even worse, open source my game. Is this correct?

Can anyone else here who has had the same issues with PhysicsFS please enlighten me?

Thanks everyone!

My only choice appears to be to use only the zip format instead, which is also licensed with the zlib license. This would save me having to provide source for a modified version of PhysicsFS along with my game, or even worse, open source my game. Is this correct?

Only a lawyer could give you a proper answer here, but I fear, that you are right track. I myself keep away from LGPL/GPL and use MIT/zlib licensed libs instead (I use static linking too).

Although you need to differ between container-format and compression. The zip file format is just a container format. Are you interested in using a certain container format or are you interested in using a certain compression algo ? Zip/zlib compression is really widely used in the open sources community (eg. java archives, open office archives etc.), so it doesn't seem to be a bad choice. Does the legal headache justify the use of LMZA/7-zip ?

The 7-Zip application is LGPL, but the LZMA SDK is public domain.

The 7-Zip application is LGPL, but the LZMA SDK is public domain.

Thanks. I think looking at it internally the PhysicsFS code took the 7-zip application and adapted it for use inside PhysicsFS rather than just directly using the SDK. If you look under physfs-2.0.3/lzma, you'll see it in here along with the LGPL license file.

This leaves it questionable to use LZMA at all within PhysicsFS without modifying PhysicsFS to correctly use the SDK instead, right?

This could be a lot of development work to adjust it...

Edit: You can also prove that they just used the application for their purposes because if you accidentally try and build PhysicsFS as an exe, rather than a library, you get both a lib, and an exe copy of the 7zip command line utility. ugh.

and,

Does the legal headache justify the use of LMZA/7-zip ?

No, it doesn't seem worth the time to change the library around, or to risk the legal technicalities of using 7-zip, i might as well just use zip files.

Thanks everyone!

What's wrong with LGPL?

GPL can't be used in closed-source projects, but LGPL can if you dynamically link to the library. Only changes to the LGPL library itself need to be shared.

Dynamically linking is difficult on smartphones, but works fine for Win, Mac, Linux.

If you must have another license, contact the owners and ask. If they are never informed that their license is unusable to some developers, how can they change it? They might not change it instantly, but maybe it'll lead them to change it down the road for other developers.

I can't dynamically link to 7 zip because the physicsfs library that uses it doesn't support dynamically linking against those components at all.

I've decided instead of dealing with the dubious legalities introduced by the oddball programming in physicsfs I'm just going to use zip format as the licensing is simpler. It makes the archive about 15% bigger but this isn't really an issue at all.

What's wrong with LGPL?

Technically the annoying part is that LGPL needs for you to allow the reverse engineering of your software for the purpose of switching the LGPL library. Now, how much reverse engineering would need to be considered "enough" for that? That's the tricky part.

You'd need to architect your code so the boundaries between the LGPL lib and the rest of the application are well defined and publicly documented. Otherwise people can claim they were reverse engineering your application for replacing the LGPL lib with another version and they just happened to come across say, your super secret map generation code, or your DRM routines.

Now, I haven't come across these things happening and its not like crackers first check if there is any LGPL licenced software being used before cracking an application. So I'm not going to say its something you really need to worry about, just have it in mind.

You also need to allow the user to be able to drop in a new version of the lib and the intention to be for it just to work with the new version. Usually this isn't technically possible without recompiling as open source authors don't really think with backwards binary compatibility in mind.
So, how far do you go with supporting this oddball clause?

I suppose I could speak to the 7zip authors about changing the license or licensing it separately for me, but if zip is fine, it is just taking up time I could use developing the game...

You also need to allow the user to be able to drop in a new version of the lib and the intention to be for it just to work with the new version. Usually this isn't technically possible without recompiling as open source authors don't really think with backwards binary compatibility in mind.

That's why the reverse engineering part is there, because if it a drop in replacement doesn't works, user needs to be able to reverse engineer the application to make it work. It doesn't demands of you to keep it compatible forever.

Couldn't you simply link dynamically to PhysFS?
PhysFS would then be statically linked to 7zip, which would be allowed, but your app would not be statically linked to 7zip.