Lars Trieloff's Collaboration Weblog

Via Dave Johnson I learn that there is a proposal to move JSPWiki to the Apache Incubator, which I regard as a great idea as the Apache Community and the JSPWiki community could benefit from each other and JSPWiki one of the two Wiki systems I use daily.

In the last days I've read some interesting posts on commercial Open Source licensing considerations. The start makes Fabrizio Capobianco with My Honest Dual Licensing

For Fabrizio, just be honest is the guiding principle for open source licensing. If you would like to develop an open source software infrastructure component like a relational database or an J2EE container, dual licensing is the way to go, because it requires users either to contribute back their modifications or contribute money to the project. This is not as easy for Open Source applications, because the relevant users often do not care about modifications, so it is much harder to encourage contributions, either monetary or code contributions.

The approach of splitting the product into an closed source part which is paid for and an open source part which contains fewer features, is dismissed, because

The risk is that your product manager will have to think where to put every new single feature, with your investors and sales people telling him/her "close" and the community shouting "open". It creates tension in the community ("why did you put THAT feature in the commercial product? We need it! We'll build it ourselves").

Another problem with dual-licensing occurs when you consider copyleft licenses like the GPL, which require you to distribute all modifications under the terms of the same license, except you are the copyright holder, which would allow you to change the license for a commercial offering. There are two limitations of the approach. On the one hand it requires contributors to the project that are not employees of the company owning the project to license their contributions under a different license than the original project. This means in effect, giving up your copyright, so that an commercial entity can take it to make money from it. An example is the MySQL Contributor License Agreement. As Karl Fogel writes in the Dual Licensing chapter of Producing Open Source Software:

The attractiveness of dual licensing is that, at its best, it provides a way for a free software project to get a reliable income stream. Unfortunately, it can also interfere with the normal dynamics of open source projects. The problem is that any volunteer who makes a code contribution is now contributing to two distinct entities: the free version of the code and the proprietary version. While the contributor will be comfortable contributing to the free version, since that's the norm in open source projects, she may feel funny about contributing to someone else's semi-proprietary revenue stream. The awkwardness is exacerbated by the fact that in dual licensing, the copyright owner really needs to gather formal, signed copyright assignments from all contributors, in order to protect itself from a disgruntled contributor later claiming a percentage of royalties from the proprietary stream. The process of collecting these assignment papers means that contributors are starkly confronted with the fact that they are doing work that makes money for someone else.

To come back to Fabrizio's solution: He proposes to cut between customer groups, not feature groups. For one customer group, namely the Open Source community, the product will be visible as a free, Open Source product, for other customers, the aspect of monetary contribution is highlighted:

It is quite simple, actually: we will not segment your product based on features, we will segment our user base. On one side, we build a phenomenal open source product targeted to your open source community, pure and honest. On the other side, we build a commercial product based on the same core BUT targeted to someone else. If "someone else" is not in your open source community, you are golden. Your community grows happy giving back the code to the project, your "someone else" pays for it and gets back what it needs (quid pro quo).

Matt Asay adds some comments in his post Honest dual licensing (Fabrizio/Funambol), which focuses on Alfresco's Open Source strategy, which means completely dropping dual licensing and going with services and support .

In Alfresco's case, we moved to a 100% open source model for various reasons (not the one Fabrizio suggests - the model was financially quite good to us). One was that it correlated better to our personal beliefs - I, in particularly, never liked the mixed-source message I had to say while at my previous employer. It never felt right.

This is similar to JBoss' policy of using the LGPL and shared copyright to make sure not to bait and switch by offering a closed source fork.

To finish this round-up, I would like to link to Will Price and his writeup of discussions on the optimal Open Source Business model going on at OSCON. He reflects Matt's and Fabrizio's comments by summing up:

Another common view was that dual-license models are the optimal approach. The dual-license model – like MySQL – is premised on a single product that is common independent of license (GPL or commercial). Other approaches involve offering two products – a stripped down open source version and a commercial version with full bells and whistles. Many executives I spoke with view the latter as inconsistent with the open source value proposition and prefer a reciprocal relationship whereby users either pay with contributions back into the project (GPL) or with money (enterprise).

From my point of view, symmetry is an important aspect of honesty. Don't expect your contributors to contribute under different license terms than you chose for distributing your software. From this point of view, the JBoss model is very honest, because it clearly states: JBoss is open source for everyone and a model like Mergere that uses ASF licensed software by supporting the Apache Maven project is honest as well, because everyone can offer a commercial fork at the same terms.