lundi 21 novembre 2005

Marc from Cocoon, a class act A cross-Europe hat's-off to Marc from Cocoon-land. A sales guy from Tridion pinged him for "ny doubts, uncertainties, fears there are about using" Plone. I really liked the points Marc made afterwards, as well as the comments: "...people start using FUD when they can no longer win the business on their own strength." I wonder if OSCOM.org should start a petition, where each open source CMS signs up for a pledge to do for each other what Marc did for Plone. Updated: Tony Byrne at CMSWatch wrote a quick article about this. 8:06:52 PM   comment []

Zope and the GPL I'd like to collect some input on a meme that has gone around: is Plone a "bad" Zope citizen for using the GPL? Sidnei and I chatted about this point a bit. Below are my thoughts and Sidnei wrote a weblog post with his thoughts. As background, Zope has a Zope-specific license, the Zope Public License. The ZPL is essentially the Apache 1 license sans attribution. Specifically, it doesn't require attribution and doesn't contain "viral" clauses. Zope is an application server that historically has been used to build systems for managing web content. These Zope add-on "products" sit atop the Zope "platform", similar to how Zope itself sits atop the Python runtime. Python plus Zope plus add-on product makes up a software stack. (The CMF is sometimes a layer in this stack also.) During this year, I've heard from a few people that felt Plone, a Zope add-on "product", broke a social contract by using the GPL for its license. I've also heard that this is a primary cause for antipathy from the Zope layer towards Plone. Thus I'd like to know more about this, as parts of it make sense but parts are confusing to me. The complaint, as I understand it, is that using the GPL equates to stealing from Zope: "The Zope license is permissive and non-viral, and its work can be incorporated into a GPL product, but the reverse isn't true." The argument is that Plone should have chosen the ZPL as its license, and that chosing the GPL was an act of bad faith on Plone's part. That's the highest-heat part of the complaint. I have also heard statements that ZPL permits commercial use and GPL doesn't. Also, if everybody used the same license, it would make things easier for users. I confess to much sympathy for this position, especially since I'm quite agnostic on license choices. In fact, my sympathy applies both to the substance and to the spirit of the complaint. I also realize I'm likely missing some points and nuance. (Feel free to email me in private and share your point of view.) On the other hand, I'm quite convinced there's another side to this story. First, I'm surprised that the complaint is only directed at Plone, as there are many more non-ZPL'd content management products than ZPL'd content management products: GPL: CPS, union.cms, Plone, iungo, ZMS, Bebop, and SchoolTool Non-ZPL/Non-GPL: ZC's commercial CMS product and Canonical's Launchpad ZPL: The Silva license is, I believe, essentially the ZPL. I believe (but couldn't confirm) that Tiks is ZPL. So, in a cursory overview, there are 7 GPL projects, 9 non-ZPL, and 2 ZPL. For some reason, though, Plone gets the negative vibe. I think it would be more constructive to find out why so many chose GPL, and find out if there is consensus on changing the situation. Next, if the GPL is a one-way street, then closed-source commercial add-ons are a one-way superhighway. One shouldn't complain about a GPL add-on product, and then distribute a closed-source add-on. Something seems illogical about that combination. The GPL is a lot more open and less viral than proprietary code. Here's another part I've wondered about: if we should minimize license issues to maximize sharing, and if being more Pythonic is also a goal, shouldn't we use the Python license regime? I like the idea of Plone being better Zope citizens, but I think Zope should do the same with Python. In my opinion, there is little compelling reason for Zope to have its own home-grown license, which has historically been a barrier for incorporating non-Zope code from Python. I also wonder about the practical effect. Archetypes changed its license from GPL to BSD, at the instigation of those who said it they couldn't use it otherwise. However, after the change, those people still ignored it. I am somewhat skeptical that sharing a common license will, by itself, lead to interest in the code. These other points make me wonder if there is a different issue that is the root cause. Also, I wonder if the root solutions are different than the standard prescriptions. First 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. Second solution: Take the complaint one step further, converging not on Zope's license regime, but on Python's license regime. This means we can contribute code using widely-accepted licenses and slowly get rid of the ZPL. 4:47:14 PM   comment []