Jochem van Dieten wrote: > The GPL requires that you provide the source code of every > application that incorporates or links a GPL licensed library to > everybody that has obtained a compiled version from you without > limits on change, use or redistribution other then the GPL itself.
There's one little proviso that many people miss out here. You can still use GPLed libraries in commercial apps without releasing your source just as long as the GPLed libraries and the commercial code don't touch. There's a few ways in which this can be done. These depend on forms of loose coupling, making the result a mere aggregation as opposed to a derivative work. Dynamic Linking =============== Pretty obvious is this one. The GPLed code is in a seperate library and is only linked into your app at compile time. Examples of this would be kernel modules and drivers in Linux (which itself is GPLed), DLLs and SOs, jar files (so long as your compiled class files are in one jar and the GPLed code is in another). Aside: With Java and similar languages, the issue of subclassing comes up. In this case, if you subclass a GPLed class, your class is a derivative work and therefore subject the GPL. Interfaces, I believe, are a different matter. Aside: The GPL FAQ disagree with me on this. However, the GPL, if my reading is correct, says nothing that disallows what I've stated above. The reason for this is that when you dynamically link to a library, you leave hooks there for the dynamic linker to resolve. Supposing even a wholly hypothetical library, equivalent in functionality to the GPLed one, that is licensed in such a way as to allow redistribution without the kind of restrictions as the GPLed library and can be dropped in in place of the GPLed library for the dynamic linker to resolve the hooks at runtime without needing a recompile of your program, then that your program is dynamically linked to a GPLed library at run time is more an artifact of the system it's running on rather than something inherent to your program, rendering it a mere aggregation rather than a derivative work. Phew, that was a long sentence! Thunking Layers =============== You write a small wrapper library that talks to the GPLed code. Dynamic Linking is a variant of sorts on this, but in this case you're doing everything manually rather than automatically, and the GPLed code will still probably be statically linked anyway. You then license the wrapper library under a suitable GPL-compatible license, such as the BSD license or LGPL. How this gets away with it in a legal sense is that the fact the wrapper library depends on a GPLed library is simply an implementation detail of that library and not one that your app depends on. You can, for instance, use a completely different library, and modify the wrapper library's implementation without it affecting your code. This is the safest option. If you want to be extra safe, dynamically link your wrapper library rather than statically linking it to the GPLed library might be your best bet. As an example of this. Say the expat XML parser was covered by the GPL (it's not, but bear with me). A few years back, I wrote a rather neat class in C++ to act as a wrapper around it. It used a bunch of static private methods as callbacks, and a pointer to the instance in question as the userData. Say I release this class and make it available under the LGPL, BSD license or some other GPL-compatible license. Now I go and write some app that uses this class and release it commercially. My app depends on the wrapper class, but on expat only as an implementation detail of the wrapper class. I could just as easily recode the wrapper class to use libxml2, msxml, or some other parser. > The GPL is often called 'viral' because using a little bit of GPL > code in an application 'infects' the rest of the application. The > LGPL does not have this problem. But it is important to recognize > that nobody can force you to give away your sourcecode. If you > don't adhere to the GPL you are violating IP law and somebody > might claim damages, but the law does not recognise "open-source > your own code" as a remedy. OTOH, it doesn't need to recognise it. Licenses are part of contract law, and its under contract law that the arguments would be made. The GPL is a contract that states that if you create a derivative work of a piece of software covered by the GPL and distribute the derivative work, you must make the source code of the derivative work available upon request. K. PS. Jochem, you don't mind if I post this on my blog, do you? ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| Find out how CFTicket can increase your company's customer support efficiency by 100% http://www.houseoffusion.com/banners/view.cfm?bannerid=49 Message: http://www.houseoffusion.com/lists.cfm/link=i:4:205577 Archives: http://www.houseoffusion.com/cf_lists/threads.cfm/4 Subscription: http://www.houseoffusion.com/lists.cfm/link=s:4 Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4 Donations & Support: http://www.houseoffusion.com/tiny.cfm/54
