The general gist is that Zope uses the Zope Public License (ZPL) which is modeled after the Apache 1 license and is less restrictive than Plone's GPL license. Plone's use of a more restrictive license is thought by some to be uncooperative with the Zope community and confusing to users. I think Paul raises an excellent point that Zope did the exact same thing by not adopting the OSI Certified Python license.
However, Chris McDonough, in the comments of Paul's blog, raises a very good point that developers on the Plone platform tend to commit code to both Zope and Plone and having different licensing schemes makes things unnecessarily complicated. I definitely hear that. You don't want licensing terms to determine where your code belongs.
I don't think that this problem is going to get solved but I don't think that it necessarily needs to. Paul has a nice status quo solution:
Forget about product re-use. Instead, focus more on avoiding duplication of framework stuff. When somebody needs to do something, get them to do it at the right stack layer, under that layer's license. This is the goal of Goldegg. I think this is a more useful and realistic answer to code sharing in the stack.
By "forget about product reuse" Paul means trying to do things like using a piece of Plone in another (possibly proprietary) product. I think this solution makes sense and it is certainly more actionable than trying to get everyone to change their licensing schemes.