When discussing the merits of open-source with business people, it's still not uncommon to hear that age-old question: how does it make money? It's a question that's becoming less common as business minds have come to appreciate and understand the open-source way, but when it does come up, it can be tricky to answer. Business models based on open-source usually talk about long-term investments or sales of support contracts, but there's one increasingly popular model that's dead simple for business types to understand: dual licencing.
With dual licensing, software is offered under both an open-source licence, typically the GPL, and a commercial, proprietary-friendly license. Anyone happy to work within the terms of the GPL can use the software for free, just like any other GPL project, but if you're building a proprietary project with other terms in mind, you can fork out the cash for a commercial licence that frees you from the GPL's open-source restrictions. Trolltech's Qt toolkit is an excellent example: it can be used freely under the GPL in open-source applications, but if you're building a closed-source app, a commercial licence is in order. MySQL, another dual-licensed application, is often used in GPL form in proprietary deployments because it runs as a stand-alone server, rather than being linked in to your application. However, embedding it in to proprietary applications is possible with a commercial licence.
Beware the licence
At first, dual-licencing seems like a win-win situation for the developers and the open-source community, combining aspects of both open-source and proprietary development models. We get free access to some great software, the developers build a user base and a lot of good will, and all while the cash keeps rolling in from the paying customers. If you look a little deeper though, dual-licencing eliminates some of the benefits of open source, while bringing along some of the commercial world's concerns as well.
In a typical open source application, development is a co-operative process, with various developers bringing their skills together across the Internet, and with users often having direct input in to the way the project runs. However, in a dual-licenced application, the majority of code comes from the owning company's paid developers. Few outsiders feel compelled to contribute, since doing so usually requires assigning copyright to the owning company, allowing them to sell it under their proprietary licences.
Another strength that disappears under the dual-licence model is open source's natural resistance to buyouts. You can't buy out an open source app, but when one company pays all the coders and holds all the copyrights, buying them out comes a pretty close second. The new owners could easily stop distribution of new open-source versions, and even though they can't stop distribution of existing releases, building a co-operative development team to continue work on the open-source tree would be no mean feat.
MySQL, oh my
Now, all of this talk of buyouts might sound a little hypothetical, but it's a dilemma that's currently facing MySQL, one of the best-known open-source applications. Many of MySQL's recent improvements have been thanks to InnoDB, a table type developed by Finnish company Innobase. In the same way that Linux can use multiple filesystems, like ext3 and XFS, MySQL has various table types for storing database information, but only InnoDB can compete with the likes of PostgreSQL and Oracle.
Rumours had been running around about Oracle buying out MySQL, to slow its progress as a major competitor, but nothing ever eventuated from them. Oracle may have managed the next best thing though, because a few months ago they bought Innobase. Like MySQL, InnoDB is dual-licenced, so MySQL can give it away under the GPL while selling it to paying customers under commercial licences, which could be quite detrimental to the open-source community, and to MySQL.
Now, I wouldn't expect Oracle to remove GPL licencing as an option on InnoDB -I think it knows better than to try to kill an open-source project while it continues to push Linux as its preferred OS -- but MySQL's commercial licence could well be in jeopardy. Without that licence, MySQL would have to remove InnoDB from their proprietary codebase.
As far as I see it, MySQL now has three options -- hope to hell that Oracle plays fairly, start working on an InnoDB replacement, or give up the dual licence model and use a services and support model to support further open-source development. Oracle has stated that it intends to negotiate an extension when the current licence expires later this year, but I wouldn't put much faith in that, and I don't think MySQL will either. Going fully open source is similarly unlikely, since customers relying on commercial licences would be left without an upgrade path.
MySQL may have little option but to work on an InnoDB replacement, but whether or not they're capable of one is debatable. The older MyISAM table type is fundamentally incapable of being expanded with the needed functionality. MySQL may have considered expanding on the BDB table type, an earlier attempt to introduce an advanced table type based on the Berkeley DB library, but Oracle may have cut them off there as well. Berkeley DB is -- you guessed it -- dual-licenced, and Oracle just bought its developer, Sleepycat Software.
Of course, Oracle's motives may not be so underhanded -- they could simply have bought Innobase and Sleepycat as money-making business that they intend to keep running as they are now. We'll just have to keep an eye on them over the next year to see just what kind of impact their purchases will have. Either way, they've made the potential threat to dual-licenced projects clear.
Dual-licenced projects won't be disappearing any time soon, and I am glad for that -- they may not be quite as resistant to the whims of software giants as more traditional open-source projects, but they're still open-source, free for us to use as long as we stay within the limits of their licences.