On Wed, Jun 20, 2001 at 06:27:08PM +0200, Erik Enge wrote:
On 20 Jun 2001, Federico Di Gregorio wrote:
i am sure that the QPL and the ZPL are completely incompatible but nobody cares because nobody really thinks that one is better than the other...
I might be misunderstanding here, if that's the case I appologies.
Just to clarify, for us at Thingamy (and I'm quite sure this is the real case behind the license issues) it comes down to business-issues. I do very much care whether or not I can use a GPL Zope Python Product with my ZPL/TPL Zope Python Product. If I can't, and someone tells me I need to relicense my product as GPL it would be very bad.
An example could be if I had application G, Z, P. G is a GPL'ed Zope Python Product, Z is a ZPL/TPL Zope Python Product and P is some proprietory stuff I developed for my client. Now, if the proprietory application P interacts with my Z application and Z needs to become GPL, then that would/could require the proprietary stuff I did for the client to become GPL as well.
You're not allowed to distribute a derived work of GPL code with proprietary code incorporated. I. e. if you want to use that GPL code in your work, you'll have to make the proprietary code available under a GPL-compatible license as well (not necessarily the GPL itself). The Zope license doesn't even get into the play here. It's all between the GPL and your proprietary license. The crucial point is whether a work is a derived work of GPL code. The FSF says that mixing pieces of proprietary and GPL scripts in an application is a derived work indeed. Other people deny this. Gregor