Section 5.4. Dual Licensing

5.4. Dual Licensing

Dual licensing exploits these attributes of copyright law to construct profitable businesses using open source software. The software's owner distributes a single product under both an open source license and a proprietary license. Open source licensees pay no fees, but make certain promises. Proprietary licensees have different rights, and pay a fee for that consideration.

By making the software available on open source terms, the owner creates a large and inexpensive distribution channel. Generally, users can download the software on the Internet for free. In many cases, the software is bundled with third-party offerings, and is distributed by others not formally affiliated with the owner. Open source distribution makes the software ubiquitous, putting it in the hands of many users at very low cost.

5.4.1. Reciprocity

Open source, as it has emerged from the academic world, emphasizes the importance of reciprocity. Fundamentally, everyone in the community is allowed to share the benefits of the code that others have written. Everyone is expected to share their work, however. If you give me your work for free, I reciprocate and give you my work on the same terms. This emphasis on reciprocity encourages collaboration and allows the community to build better software than any small group could on its own.

In a dual-licensing business, the open source license demands reciprocity. If a customer uses the software under the open source license, his own additionswhich may well include the code for his own productmust be open source, as well.

Under the proprietary license, by contrast, reciprocity is not required. The customer's own code, and any changes or additions he makes to the original product, can remain proprietary.

This distinction between the two licenses is crucial. Sharing source code is a virtue in the open source community, but is a serious competitive disadvantage in many commercial settings. Proprietary software vendors would much rather pay money than give away the competitive advantage inherent in their source code.

5.4.2. Warranty

A warranty is a promise. These promises are the bedrock of most commercial relationships. Software vendors that use proprietary licenses to do business with their customers and suppliers use warranties to spell out clearly what each party expects from the other.

As a software vendor, I might warrant that my software product will work as documented, and that I will fix any errors if it does not. I will generally warrant that I wrote the software, and that I am the person who owns it. I may ask my customer to warrant that he will not give my software away for free to anyone else. If either of us breaks one of these promises, our licensing agreement will usually spell out the steps that the other party can take to fix the problem. If we cannot fix the problem, either of us can sue the other in court for breakingthe promise.

People do not generally make promises casually. There are real costs in keeping your word. For example, if I have promised that my software works, and it does not, I need to spend time, and possibly money, to fix it.

Virtually all open source licensesand certainly all those used by dual-licensing businessesare "as is" licenses, with no warranties, no promises, and no recourse in the event of problems. The user gets the software as is, and assumes all risk in using it. This allows the business to minimize business risk from users of its software who did not pay a license fee. Put simply, if the user does not pay for the license, the owner will not use his money to protect the user in the case of a problem.

Proprietary licenses, by contrast, generally include clear warranties. A company can afford to make promises to its paying customers, because it can use some of the money paid to defray the costs of keeping the promise.

Depending on how a customer plans to use a software package, he may or may not be able to tolerate the "as is" nature of an open source license. If the customer is willing to risk problems in the software, and to fix those problems himself, the open source license is fine. On the other hand, if the customer plans to ship the software to customers of his own, he may want the assurance of a committed partner behind him. Likewise, if the customer runs mission-critical infrastructure on open source software, he may need the confidence that commercial warranties provide.

5.4.3. Competitive Issues

Many vendors that consider dual-licensing strategies are concerned with competition.

Naturally, open source distribution presupposes that there are no valuable proprietary techniques in the software that need to be kept secret. If an owner distributes a software package in source form, competitors can read the source code, just like any other person who receives a copy.

This seems at first like it should be a major concern, but in point of fact, the amount of innovation in the software market is much smaller than is generally supposed. Especially in relatively mature sectors of technology, such as operating systems and databases, the techniques and algorithms are well understood by all the suppliers The combination of particular techniques that any single vendor uses may be somewhat interesting to its competitors. All of the vendors in a market hire from the same pool of technical talent, and even poach employees from one another. As a result, most vendors know pretty well how their competitors' products work.

Proprietary vendors will naturally claim that their products are novel and innovative, and must be kept secret. The problem is that there is no way to test this assertion, since doing so requires examination of the source code, and that is precisely what the vendors cannot permit, yet still protect their market positions.

In some cases, these claims are no doubt true. The strategy of concealment, however, does not distinguish between ugliness and beauty, and may be used to hide either.

A different competitive concern arises from confusion between ownership and licensing. Some vendors considering dual licensing worry that their competitors will download the open source version of the product and license it under proprietary terms to others. In effect, this would allow a competitor to use the vendor's own product to compete with him.

Copyright law, of course, prohibits this. Only the owner has the right to grant proprietary licenses to the software. In fact, no competitor can copy pieces of the work into its own products, since those products would then be forced to comply with the terms of the open source license.

There is another, subtler, force that protects dual-licensing vendors from unscrupulous competition. Open source software is preemptive: the existence of a quality open source package makes it very difficult or impossible to introduce a for-fee competitor. The cost of building such a competitive offering has to be recovered somehow. If a no-cost offering is available, selling an alternative for a fee will likely fail. The result is that very few businesses are willing to challenge open source software in the market once it is established.

The converse, of course, is not true. Open source frequently, and aggressively, challenges established proprietary software.

Even in cases where proprietary alternatives exist, dual licensing creates competitive advantage. The open source product is ubiquitous as a result of an inexpensive distribution channel. In addition, the fact that many users are able to use the software at no charge actually takes money away from purely proprietary vendors in the market. If a user can choose between a good open source product for free, and a competitive proprietary product for a fee, the for-pay competitive vendor is likely to lose the sale. Dual-licensing vendors are not paid by their open source users. Neither, however, are their competitors.

5.4.4. Ownership

Only the owner of a work has the standing to offer it to different users under different licenses. As a consequence, dual licensing works only if there is a single, well-defined owner of a work. Otherwise, customers have no single entity with whom to negotiate their license terms. In practice, projects that use the open source development model (a large community of independent programmers collaborating on a work) are poor candidates for dual licensing. There are just too many contributors to contact for permission every time a new customer wants to license the software under non-open source terms.

As a result, dual-licensing businesses do not use the open source development model. Instead, they invest in the development of the open source software and do not accept contributions from the community at large. Dual-licensing businesses rely on open source as a distribution strategy, not as a production strategy.

Ownership is an issue in the larger open source community, of course. As a practical matter, assessing the provenance of contributions to an open source project is hard. Individual contributors are often judgment-proof, and ensuring that they have not misappropriated the intellectual property they contribute to the project requires real diligence. Projects manage this problem the same way that proprietary vendors dothey put experienced managers over coders to review contributions, and they rely on mature and experienced contributors to build the product.

In fact, this ownership issue cuts both ways. Proprietary vendors are equally at risk from employees who take pieces of open source software and incorporate it into the proprietary products that their employers build.

The answer for both proprietary and open source developers, of course, is to set up formal policies and standards on intellectual property use. Diligence is simply part of the job. Both proprietary and open source developers can and do write large, sophisticated products without stealing from others.