   Opinions on using this GPL'ed library
  My client wants me to use #ziplib to add ZIP file support to our project. I'm have some concerns and questions, all based on the fact that #ziplib is released under the GPL.This project is not being publically released. It's an internal project, so this may not be an issue at all (however, I do know that Google used to get flack from the FSF for their proprietary changes to Linux that they did not release, even though they only use it internally).This is the license statement for #ziplib:Quote:LicenseThe library is released under the GPL with the following exception: Linking this library statically or dynamically with other modules is making a combined work based on this library. Thus, the terms and conditions of the GNU General Public License cover the whole combination.As a special exception, the copyright holders of this library give you permission to link this library with independent modules to produce an executable, regardless of the license terms of these independent modules, and to copy and distribute the resulting executable under terms of your choice, provided that you also meet, for each linked independent module, the terms and conditions of the license of that module. An independent module is a module which is not derived from or based on this library. If you modify this library, you may extend this exception to your version of the library, but you are not obligated to do so. If you do not wish to do so, delete this exception statement from your version. Note The exception is changed to reflect the latest GNU Classpath exception. Older versions of #ziplib did have another exception, but the new one is clearer and it doesn't break compatibility with the old one. Bottom line In plain English this means you can use this library in commercial closed-source applicationsfor reference, here is a link to the GPL v3.Now, I know that normally, using a GPL'ed DLL in your project will require your project to also be GPL'ed. The IC#Code developers say that, as long as you don't modify the project, you can use the DLL without GPL'ing your project. It doesn't seem likely that the IC#Code developers can make that exception. If they say "we're releasing under the GPL," shouldn't they have to require full adherence to the GPL? It sounds like they are intending use of the LGPL, but don't mention it.At this point, I'm thinking we should just get a waiver of responsibility, having the client claim it fully in case this isn't kosher.   
  That's a rather confusing exception. I can't quite parse it. BTW, if you want a slightly less encumbering (I think) license, 7-zip can process a gigantic range of formats, and is available under the LGPL.   ;  Something doesn't rhyme:Quote:This project is not being publically released. It's an internal project, so this may not be an issue at allQuote:At this point, I'm thinking we should just get a waiver of responsibility, having the client claim it fully in case this isn't kosher.So, is it an internal project or is it work for a client? If it's internal (to *your* company) then it doesn't matter. GPL only applies to distribution and internal use is not distribution. If you build it for a client then it's more complicated, because it depends on who's contracting who. It your client hired you for some kind of internal (for the client) project, i.e. you're a "hired hand" then it's okay. OTOH, If it's your company selling a product (even if it's a one-off custom product) then it's distribution and the full GPL applies.But for ziplib it doesn't matter. As you quoted, they have an exception that allows you to link with it. As long as you don't change the source of ziplib, and give your client a GPL license + source of ziplib (not your entire app, just ziplib) then you're good.Oh, IANAL ofcourse and this ain't legal advice. But this is how I understand it (and I deal with GPL a lot).   ;Quote:Original post by SanderIf your client hired you for some kind of internal (for the client) project, i.e. you're a "hired hand" then it's okay.Yes, this is the situation. It's part of their internal systems.Quote:But for ziplib it doesn't matter. As you quoted, they have an exception that allows you to link with it. As long as you don't change the source of ziplib, and give your client a GPL license + source of ziplib (not your entire app, just ziplib) then you're good.Oh, IANAL ofcourse and this ain't legal advice. But this is how I understand it (and I deal with GPL a lot).It's kind of crappy that they have to say "based on the GPL, gotta GPL your stuff if you dynamically link, but if you don't change the code, you don't have to GPL." It seems like they make the assumption that people are going to change the code before using it. I just want ZIP support for my .NET app, why would I change it?My understanding was that the GPL didn't permit "mixing and matching" licenses that were not compatible with the GPL. Having this proviso that one my dynamically link an unmodified version without fear seems to indicate that the IC#Code developers didn't do their own homework on what is and is not kosher with the GPL. My client says "I don't care, we use it all the time, just do it," but I know he tends to jump the gun on stuff and do whatever he pleases. I'd really rather not have a lawsuit open up just because someone couldn't be bothered to stop and ask "can we actually get away with doing this?"Oh hell, I might as well develop my own library in my spare time just to be sure.   ;  I was under the impression .NET already had basic functionality for reading from ZIP-compressed archives.The classpath exception in the GNU GPL exists because of the Java open-source project; they want to GPL everything (JVM, JDK standard library) but the ability to link non-GPL programs to the Java standard library is not compromised.You will be fine. In your case, you are dynamically linking to the Classpath-licensed library, but your project is not covered under the GPL as a result. You do have to provide the GPL source to #ziplib if someone asks, and you have to provide any modifications you made to #ziplib, but I doubt this will occur.IIRC, you can mix LGPL and GPL inside the same project (and in fact, LGPL exists for this very reason), so I'm not quite sure why the classpath license exists. I assume the classpath license allows for static linking, which LGPL certainly doesn't.I would email the authors asking them why they picked Classpath instead of LGPL.Edit: System.IO.Compression   ;  wouldn't a workaround for this is to make a service that provides the functionality, then just have your application communicate with the service. This way you only have to provide the source for the service rather than entire project.   ;Quote:Original post by RavuyaI would email the authors asking them why they picked Classpath instead of LGPL.If I had to guess, I'd point to strong signing. The crux of the LGPL is that you (the end user) should be able to replace the library in question and have the application run on top of the new version. Strong signing makes this impossible to do, by design. By my reading, the GNU Classpath exception does not require this ability.   ;Quote:Original post by PromitQuote:Original post by RavuyaI would email the authors asking them why they picked Classpath instead of LGPL.If I had to guess, I'd point to strong signing. The crux of the LGPL is that you (the end user) should be able to replace the library in question and have the application run on top of the new version. Strong signing makes this impossible to do, by design. By my reading, the GNU Classpath exception does not require this ability.Oh! Good point. I hadn't considered that, but you're probably right.   ;Quote:Original post by RavuyaEdit: System.IO.CompressionI should have mentioned that there is a specific need for the PKZIP scheme, as we are only reading from ZIP files, and not writing anything. I had checked that out before. It comes with DeflatorStream and GZipStream. I don't know much about compression, but I tried the examples for both, and neither of them work on my test data from my client. GZipStream complains about a missing magic number, and DeflatorStream complains about buffer sizes not being matched, or something. I'll look into it a little more, but it doesn't appear to be working too well.The ZIP spec is "only" 52 pages long, and that includes a changelog for the majority of the life of ZIP, as well as uncommon extensions. I know I won't be supporting things like password protection, so implementing a cut-down version wouldn't be hard.We had a long discussion about this with the client today. They are of the perspective that the project is private-use, not being publically released, so there are no issues. Someone mentioned that the FSF was unsuccesful in doing anything to Google over changes to Linux, so that sounds like it's okay. At any rate, I have advised them of my opinion, I got my letter authorizing the use of the library from the client, so my company is officially off the hook.   ;Quote:I assume the classpath license allows for static linking, which LGPL certainly doesn't.correct   