Previously Jens Vagelpohl wrote:
> On Mar 10, 2009, at 10:01 , Wichert Akkerman wrote:
> > Previously Jens Vagelpohl wrote:
> >> In general, commercial adoption of a software stack is made easier if
> >> it is not accompanied by a whole soup of different licenses. The  
> >> fewer
> >> licenses, the better. I'm sure that issue is on your radar already.
> >
> > It is, which is why the ZPL has already been rejected as an option: it
> > is pretty much equivalent to the BSD license, which is much more  
> > widely
> > accepted.
> If they are equivalent, why not dual-license?

What would the advantage be? The ZPL is an exercise of license
proliferation and as far as I can see gives no benefits over BSD.

> > The debate is currently focusing on GPL versus BSD license. Any  
> > opinions
> > on a choice between those two would be very welcome.
> The discussion has been rehashed in several places, but given a choice  
> between pretty much anything and the GPL I'd vote "-1" on the GPL.

I made a typo there: the discussion is focusing on LGPL versus BSD. I
suspect that will not change your vote though :)

> >> As you know, all code you'd like pushed down the stack into the CMF  
> >> or
> >> Zope must be licensed under the ZPL. That's also a prerequisite for
> >> being stored in the Zope Foundation repositories (a.k.a.  
> >>
> >
> > I do not think the Plone Foundation board is willing to consider
> > donating some of its intellectual property to the Zope Foundation. I  
> > am
> > already happy they are willing to consider selective relicensing.
> To me this really sounds like the rift has widened, by a whole lot. It  
> reads like "we're happy to base our stuff on yours, but we really  
> don't want to give back". I'm sure it's not meant that way, but it  
> reads like that.

It is not that way at all. Plone does want to give back, and by
relicensing components does exactly that. If the BSD is chosen you can
do anything you want with that Plone code, except upload it to since that implies transferring ownership, which is not
allowed. This is no different than Zope policies:  you can not
copy code from to the plone repository either. Or move code
from Repoze to Zope, from Zope to FSF, etc. etc.  The license is
not the limiting factor there, but the surrounding policies are.

> > But that does not need to be a problem: reusable packages such as
> > plone.indexer can be used by CMF even if they are not covered by the  
> > ZPL
> > or managed in, as long as there is the license is
> > acceptable.
> That's not the issue I was trying to address. I was specifically  
> talking about putting functionality in the most appropriate part of  
> the stack, meaning moving it further towards the core. If there are  
> bits and pieces that make more sense in the CMF then saying "well,  
> just install our package" may satisfy users, but developers will  
> continue wasting time maintaining different implementations.

Why would there be multiple implementations if they can just use the
existing one? I do not see that. I do agree that work should be in in
CMF itself, and this particular instance of the indexable wrappers is an
excellent example of that. I hope that in the last few years we have
already demonstrated that we really do want to work closer with the
CMF and Zope communities. 

Perhaps in the future the Plone Foundation would be willing to donate
code to the Zope Foundation. At this moment that is a bridge too far,
and I fear that as soon as I suggest that at this point in time the
entire relicensing movement will die in a never-ending debate. Lets
save that one for a later day.


Wichert Akkerman <>    It is simple to make things.                   It is hard to make things simple.
Zope-CMF maillist  -

See for bug reports and feature requests

Reply via email to