This is of course not the first time that such a debate occurs and it reminds to me some previous discussions on this subject during the crash of the NetEconomy at the beginning of the century.

First of all we are mainly discussing here about "commercial open source" business models and globally speaking how to make a living with an open sourced code base. As an introduction Matt Asay also pointed to this interesting document from SAP Research: " The Commercial Open Source Business Model".

From a commercial open source point of view there are mainly two main churches (whatever the underlying license paradigm used to reach such objectives):
- Widen the audience for a given piece of software
- Opening the whole product codebase while keeping the software editor commercial interests in place

Both are really difficult to make in parallel.

Either you want to reach the largest audience as possible and sooner the better and using a very permissive licensing schema (BSD; ASL; ...) and relying on a well known Foundation (Apache, ObjectWeb;...) will of course help foster collaboration and increase visibility. A software editor can use this approach in order to try to heavily push for a de-facto standard or to get rid of infrastructure elements that he now considers as a (soon to become) IT commodity and which will cost to him more money to maintain alone compared to the amount of related revenues. As far as I am concerned, this is typically the approach used by Day with Jackrabbit (and now Sling). Day considers that core content services are now or will very soon become a commodity and then that his customer value added relies more in some IT layers on top of such a core kernel (e.g: WCM; DAM, Portal; Social Software;...layers). So they are trying to leverage the open source community in order to attract other developers and share the further investments or maintenance costs.

  The main software contributor will however have to manage co-optition (any competitor could reuse its contributed code base potentially without contributing anything back in return). And this is often not a trivial paradigm to apply for the company management  or the shareholders as there will always be ongoing discussions coming over and over, years after years on why the company could not better monetize such a piece of code. This is also why Foundations such as Apache are requiring that committers on such contributed piece of code could rely on several different software vendors. This might help ensure a long term sustainability of the project if the original contributor’s shareholders suddenly decided to change their business model (e.g: what if Day and other JCP committers want to keep the future JCR 3.0 Reference implementation commercial?).
Such a business model could of course only be driven by selling extra-modules on top of the shared open sourced kernel from a classical and proprietary manner (or optionally through other kind of very restricted developer source license).

Or as a secondary key paradigm the software editor wants to provide to all its stakeholders a full and 100% OSI compliant access to the overall code base. The editor then has to find ways to generate from one manner or the other some license revenue streams (I do not believe in the business model which requires the sales of professional services the day and the free development of code the night).

Generally this is done by implementing a dual licensing paradigm based on the GPL license. As far as I am concerned I do not think this is the best licensing paradigm the software industry ever found. But this is currently the most common and well established one and so the one which is not creating too much confusion in the head of all the customers and partners.

On one hand the GPL still carries this image of "Open Source Fanatics" and your whole business model is based on the fear that your customers or partners could get exposed to some viral effects with some unknown but certainly terrible consequences on your existing proprietary a software and some legal law suits. This is not a very sane approach of business. On the other hand this fear was the only criteria which proved to be 100% compliant with the FOSS paradigms. Combined with the strong GPL evangelization done by the Free Software Foundation for years, IT teams and IT Managers starts to understand the high-level picture of this commercial business model (exposition to risks vs payment of some royalties) even if they generally do not understand how it really works under the table.

I personally think that the Open Source industry is still falling to implement a fair quid-pro-quo paradigm. And this fair quid-pro-quo is the basis of all human relationships for centuries (aka exchange tit for tat). Back to 2004, I already wrote an article about it in the Methods and Tools magazine: http://www.methodsandtools.com/PDF/mt200402.pdf (starting from p.20) in order to try to define a fairer business model. It was based on another essay (the Liberal Source Essay from Paul Johnson in 1999 (sic!): http://web.archive.org/web/19991005051225/http://www.elj.com/lss/ )

Jahia has always tried to implement such a quid-pro-quo paradigm whatever the underlying combinations of open source or commercial licenses being used. We started by developing our own copy of a "liberal source license" (it was the JSCL in 2002 based on the Sustainable Software Initiative: http://web.archive.org/web/20061207221650/www.sustainablesoftware.info/jahia/Jahia ). Then we switch to a dual licensing paradigm by using a derivative of the Mozilla license (more permissive than the GPL) but with a badgeware constraint (customers had to keep some logo and disclaimers in all the user interfaces while using the free version). There were a lot of passionate debates about this badgeware approach in the whole Open Source industry so we switched to the classical GPL dual licensing approach for Jahia 6.0.

But finally we are just exchanging one constraint by another one and basically the key underlying paradigm stays the same: make it difficult to use the free version if you have some commercial interests and avoid "free-riders". So the GPL viral effect is just a substitute to the Mozilla badgeware.

But what is more important and that not a lot of software vendors are really doing is to implement a fair quid-pro-quo paradigm. Because as soon as you start dealing with some dual licensing paradigms, customers are finally dealing at the end of the day with a standard commercial software vendor by acquiring a standard commercial and proprietary license.

This means that they can contribute extensions on the free version, give all the copyrights (or at least relicensing rights) to the software editor as it is often required and still have to pay for a commercial license in order to get rid of the constraints they do not want (badgeware: fear of the viral effect;....). Such customers are then paying twice: once in kind and another time in cash. And here the spirit of open source is broken. There is nothing fair any more in such a manner of working with interested contributors (= generally employed by a customer or a partner of the concerned software editor).

When managing a few years ago the Sustainable Software Initiative, I received some complains about MySQL from certain contributors and their dual licenses: they worked for months and for free on behalf of MySQL in order to help them develop some new module and finally they company had to acquire some commercial MySQL licenses. They had the feeling to be squeezed. At a certain stage in time MySQL finally offered some "Credit Points" to main contributors in order to get discounts on their commercial licenses. But I could not find this web page any more. They should have stopped doing it. It would be interested to know why (too complex to manage?)?

Jahia is of course continuing to use such a fair quid-pro-quo mechanism and several of the current Jahia features were sponsorized by customers. Finally all these debates about the pros and cons of such or such open source license paradigms is only hiding the big picture from a commercial usage perspective: who is winning what at the end? And while there is not a fair, sustainable and well established open source practice, there will be only commercial open source business models based on workarounds trying to use a FOSS compliant constraint to resell a commercial edition.

Now clearly speaking the goal of OSI or the FSF is not to enforce any quid-pro-quo paradigm. This is up to the commercial open source vendors to do it themselves. Perhaps a consortium of several commercial open source vendors could agree together in order to develop a kind of "fair-trade certificate" which would warranty certain community oriented fair-trade best practices. We already tried once here at Jahia. But perhaps it was too early (the “commercial open source” term was even not existing). Would it be interesting to give to it a second chance?