[Zope-dev] ZPL and GPL licensing issues

[Casey Duncan]

Federico Di Gregorio wrote:
> 
> On 21 Jun 2001 11:39:37 -0400, Jim Penny wrote:
> > On Thu, Jun 21, 2001 at 05:18:40PM +0200, Federico Di Gregorio wrote:
> > > On 21 Jun 2001 11:08:30 -0400, Jim Penny wrote:
> > > [snip]
> > > > OK, consider this from another point of view.  If I have an operating
> > > > system may I install a piece of GPL software on the operating system?
> > > > May I redistribute the operating system?  With the GPL software?
> > > > May I invoke/run the GPL software?
> > > >
> > > > My understanding is that the answer to every one of these is yes.
> > >
> > > yes. only if it is free. only if it is free. yes, but only because gpl
> > > allows for gpl code linking with the major components of the os even if
> > > they are proprietary.
> >
> > Uh, you might want to reconsider the "only if it is free" parts.  After
> > all Interix had a business of selling GPL software for a non-free
> > OS.  Now Microsoft has that business (NT Services for Unix Pack).
> > IBM distributes gcc and perl.  Cygwin sells GPL software for non-free
> > OS's.
> 
> ops. ok, poorly worded. third parties can distribute only if the os is
> free, vendor can do as he please, obviously...
> 
> [snip]
> > > err, no. if you write an external module using only python code, as long
> > > as you use a gpl-compatible python to run zope, you can call your
> > > external code from zope. if you write a product suclassing dc code,
> > > you're effectively 'linking' and gpl limitations apply.
> >
> > GPL limitations apply to whom:  To you, the developer?  To a
> > downstream user invoking the product via dtml-call or dtml-var or their
> > pythonish equivalents?  To a downstream developer who modifies your
> > product and redistibutes the modified product?  To a downstream
> > developer who writes a component that invokes the GPL component?
> >
> > In my mind the only sensible answers are developer - no,
> > user - no (but see Jerome Alet's codacil), downstream modifier - yes,
> > downstream developer who uses - no.
> >
> > The only other sensible option is that, indeed, no one may distribute
> > GPL components for Zope, including the original developer.
> 
> as i said before, writing gpl code subclassing zope is a non-sense. even
> the author cannot, imho, redistribute its work with a plain gpl attached
> to it. the gpl says that if you link with gpl code *all* the code should
> be gpl or gpl-compatible (major os components like clibs, compilers, etc
> are an exception). so even the author cannot do that without licensing
> under gpl plus some exception ("as a special exception you're allowed to
> link this code with zope or any other zope product distributed under the
> zpl".) see the (in)famous gpl vs. qt thread in the debian mailing lists
> for an in-depth analisys of this problem.
> 

To me this is the key point. If you GPL license a product (or other
software) for Zope, you cannot subclass ZPL coded classes in your
product without violating the GPL. This makes a strict GPL license
nearly useless for Zope development and incompatible (license-wise) with
Zope itself. What bugs me is when people point to the ZPL being the
"problem", it is the GPL that is the limiting factor IMEHO. 
-- 
| Casey Duncan
| Kaivo, Inc.
| cduncan@kaivo.com
`------------------>