Back in 1976, Bill Gates wrote an open letter to hobbyists. He asked, “Who can afford to do professional work for nothing? What hobbyist can put three years into programming, finding all the bugs, documenting his product, and distribute it for free?”
Today, Gates has to eat those words because the open-source movement has proven that it is possible to give something away for free and still make money off of it. The trick is to give it away to those who are not going to pay for it and charge those who are willing to pay for it. Oh yeah — and you have to have something that separates the two, otherwise everyone will get it for free.
New Business Model
One way to keep the separation is that the paying customers get value added features like service plans, add-ons, and other bundled products. Another way that commercial entities have managed the separation, thus making open-source development economically viable in cases where it might not have otherwise been, is by creating a “new” business model for the software industry that essentially allows companies to have their cake and eat it too. It is called dual licensing.
Some would argue that dual licensing is hardly new, but is just a modification of the “shareware” concept. The common understanding defines dual licensing as the simultaneous licensing of software under both open-source and proprietary licenses.
A more accurate definition is that dual licensing is simply the licensing of one software product under two different licenses, where one license allows for free distribution and the other allows for license revenues.
Making it Work
Why dual license? This is the most important question businesses need to ask before adopting the dual licensing approach. The biggest motivation for using the dual licensing model is to make money through price discrimination by monetizing your intellectual property. Companies like MySQL, SleepyCat and Trolltech report doubling their revenue or more through a dual licensing model.
MySQL states on its Web site, “Our software is 100 percent GPL, and if yours too is 100 percent GPL (or OSI compliant), then you never have to pay us for the licenses. In all other instances, you are better served by our commercial license.” They give away the software, yet they make money selling it.
Another important reason to use dual licensing is to ensure compatibility with other licenses. A notable example is the Mozilla Foundation’s decision to implement a tri-licensing model to license certain software under the Mozilla Public License (MPL), the General Public License and the Lesser General Public License (LGPL) in an effort to address the issue of incompatibility with the GPL, as pointed out by Richard Stallman.
Given that the GPL is by far the most widely used license for open-source projects, it makes strategic legal sense for Mozilla to close the incompatibility gap.
Mechanics of Dual Licensing
The first prerequisite of dual licensing is that the licensor needs to have control over all the copyrights or at least enough control to be able to pick the license terms. When explaining the company’s decision to dual license, MySQL CEO Marten Mickos noted, “We can do this because we own our software and have the freedom to license it any way we wish.”
You can make sure you own the copyrights by either writing all your own code or obtaining third-party licenses. In fact at SleepyCat and MySQL, all code development is done in-house.
External development can be done, but the licensor needs to ensure that copyrights are assigned from contributors before their contribution is added in. This is Mambo’s model.
The next task is to figure out which dual license to use, which is not always an easy decision. The dual license, by its name, has two licenses, one I’ll call the free license and the other I’ll call the proprietary license.
The most commonly used free license is the GPL. The reason is that it features a strong copyleft which ensures that the original copyright holder is able to gain access to the source code for all bug fixes and modifications to the original software (which is not without its own issues, see “Limitations of Dual Licensing” below) and generally limits how someone can make money of what the original developer is giving away.
Differentiating between licenses is a matter of examining the types of uses that apply. SleepyCat is one example — if a licensee intends to distribute the modified software without releasing the source code and the free license prohibits that, they need to obtain a proprietary license. Others, like Sun’s OpenOffice, have to license the source code and documentation under separate licenses.
Limitations of Dual Licensing
If your dual licensing model includes the GPL, you may get a situation where the copylefted version is better than the proprietary version. A major advantage of the open- source model is that having many pairs of eyes looking for problems makes bugs easier to find and fix.
It may be that the software released under the GPL version has a superior modification that is not found in the proprietary version. Under the GPL, you cannot fold that modification into the proprietary version without making your proprietary version subject to the GPL. You will need to monitor and keep track of your code as well third party fixes to ensure there is no tainting.
Dual licensing may not be suitable for stand-alone applications. As Mickos observed, “Unless you can impose restrictions on the end user’s application code, you don’t have the leverage you need for dual licensing.” SleepyCat, MySQL and Trolltech are all software products that are meant to be embedded in other applications.
In theory, dual licensing may lead to other companies starting a competing development project (forking) using the GPL’ed or other open-source software. However, in practice, the potential gains from the use of dual licensing as a marketing tool for widespread adoption may outweigh this risk.
In 2001, a company tried to fork from MySQL but failed because it did not control the copyright and thus could not license it under a commercial license.
Avoid Indigestion
Admittedly, dual licensing could be seen as antithetical to open-source principles, which is why to some open source advocates, the dual licensing model is just a way for commercial companies to reap the fruits of open sourcing without sharing the benefits.
Like baseball purists who can never accept the designated hitter as part of “real baseball,” open-source purists think that commercial companies are uncomfortable with “real open source” and would prefer something more “pseudo-open-source” like products offered by companies using dual-licensing.
Let’s face it, software companies are in business to make money. They can do this by selling or licensing their products and services, or they can sell combinations of both as an online subscription called application service providing (ASP). Depending on the business model they choose to use, some companies can do very well. Others may not stick around too long.
Does dual licensing make it possible for open source software companies to have their cake and eat it too? Or will it lead to a bad case of indigestion? Dual licensing is no magic bullet. Wise companies will consider their objectives and examine if their products and infrastructure can support this licensing model before they decide if it is right for them.
Phil Albert, a LinuxInsider columnist, is a patent attorney and partner with the San Francisco office of the intellectual property law firm Townsend and Townsend and Crew LLP.
Loading ...
