Dual-licensing for open source businesses

When I started to build a business around ModSecurity, back in 2004, I chose to keep complete ownership of the ModSecurity code base.  This business model is better known as dual-licensing. Keeping ownership of the code has the following advantages:

1. The product becomes (or remains) an asset; it increases the value of your business.
2. You can license the product under a different licence. For example, you can sell a version under a closed-source licence to the companies who are not fond of (or familiar with) open source licences. Similarly, you can sell OEM licences, which may be quite an interesting possibility, depending on the type of product you have.
3. Finally, you can bundle your open source product with another closed-source component and release the whole as a commercial closed-source product. This is quite a common strategy today.

Dual-licensing only makes sense when combined a viral licence such a GPLv2, in which case it helps you make your software freely available to your users, simultaneously creating a shield to guard you from your competitors—with only the open source licence to work with, the only way for them to benefit from your code is to embrace open source (which seldom happens).

As you can see, the advantages are many. But they are not free.

In return for the above benefits, you create a community of users rather than of a community of users and developers. The people interested in joining an open source project will largely do so for the reasons of passion, but the asymmetrical relationship of dual-licensed projects often stands in the way. Not only they have to justify giving you something (code rights) for nothing, but they can never hope to truly become part of the development team.

End result? You may end up with no contributors at all.

On the other hand, if you give everything away for free, you may find it difficult to pay for further development.

I spent months and years thinking about the above conundrum, and ended up believing that dual-licensing is an acceptable compromise and a viable business approach. At the end of the day, the approach probably won't give you that warm and fuzzy feeling only the participation in the open source community can, but, if successful, your project will be made available to everyone for free and it will pay you salary to keep on doing what you love.

Comments

[Christian Folini]

That sums it up quite nicely.

[Stewart Bryson]

Ivan:

I have an product I've been writing over the last few years, and can't decide whether to open source it or not. I think I'm going to take the dual-license approach as a way of feeling it out. Here are my questions:

1) What is your framework for dealing with users, as you phrase it? Do you have an agreement that you give them if they want to make contributions? Is this an awkward discussion to have?

2) I could always stop releasing it through an open source license, correct? I mean... I can't un-ring a bell, so anyone who has the source code that they received via the open source license can continue to do with that code what they want (as long as it doesn't violate the license)... but any subsequent releases could then become closed again, it seems to me.

3) I can't decide whether to go with a straight copyleft protection, such as the GPL3, or something that requires ALL changes to be resubmitted to me. I kind of like the idea of getting the changes... but in a dual-license approach, I'm not sure what they are worth, really.

[Ivan Ristic]

Hi Stewart,

My advice, first of all, would be to think very hard about why you'd be open sourcing your product. For example, one very good reason is marketing. Whether you get any users to join the project depends on many factors. For example, in the security products space, my impression (and experience from ModSecurity) is that users are not interested in getting their hands dirty. If your product is oriented toward a different class of user, perhaps toward developers, your situation may be different.

1) You have to have an agreement, and you should take the one used by the Apache Software Foundation. And, yes, it can be an awkward situation, with no one happy in the end.

2) That's correct. Whatever you put out there stays out there (under whichever licence you use), but, if you decide that you don't want to bother any more, you can choose not to open source any future versions. Basically, for as long you own it, you control it.

3) I am sure that requiring all changes to be submitted to you won't work. (Unless you get a community of users, in which case it won't matter. Sometimes you can just put a product out there for free, and it will work just fine. It really depends on your motivation and goals.)