The art and science of dual licensing

Stefano Comino and Fabio Manenti have written a useful paper [PDF] on dual licensing in open source. It's a decent resource for helping developers and vendors figure out why, if, and how to dual license their software. (See here for a useful explanation of what dual licensing means, and Heather Meeker's piece is a must read for anyone interested in the legal ramifications of the practice.)

I found myself agreeing with much of the authors' conclusions, but not necessarily the tone or conclusion, because they seem to see dual licensing as a way to drive sales. Of course, it sometimes undoubtedly is - for some time a large percentage of MySQL's, Sleepycat's, db4o's, etc. sales were motivated by a proprietary license waiting to "rescue" the OEM/customer from an open source license.

In my experience, however, offering one's software under a dual license is not necessarily an "out" for the customer, but rather a simple way of reducing uncertainty for the customer's lawyers to help expedite deals. This doesn't find a place in the authors' research:

...[D]ual licensing seems an appropriate strategy when a relevant part of the demand is generated by commercial users that need the software in order to embed it into their own products. These ?embedders? employ the source code of the software as an input in order to produce other software; the derived software may be a product per se or, more frequently, it may constitute part of the technology of a more complex system produced and sold by the embedder. In both cases, it is clear that since an embedder wants to keep proprietary control on the derived product, it prefers to receive (i.e. it is willing to pay for) the source code he/she needs to embed under a proprietary licensing scheme that does not impose reciprocity.... (4)

In other words, dual licensing seems to represent a viable business strategy for embedded software and/or when the software code represents a central piece of technology for the platforms or systems that commercial customers produce and sell. (15)

This is what I call Dual Licensing 1.0. It's old school dual licensing. Dual Licensing 2.0 is a more positive approach to the practice, because the proprietary license is there, not to drive sales, but to make sales that would close, anyway, do so a bit more efficiently (i.e., faster). This is akin to Red Hat's licensing strategy and to that which companies like Alfresco use: you get the software under a commercial contract to make the licensing process more familiar to would-be customers (including OEM partners, though I think in this case it is true that the visible-but-closed source is a draw).

So, again, in Dual Licensing 2.0 I don't see vendors using the strategy as an escape route for leery customers from the benefits and obligations of open source, but rather as a way to make the open source acquisition process more efficient. Ten years from now, I don't think it will be as useful, however, because we won't have the same bottleneck in legal. (In fact, it's already dissipating. It's amazing how much easier it is to sell open source software today than it was just a few years ago.

But for now, it works. Well.