Open Sources 2.0/Open Source: Competition and Evolution/Dual Licensing
Over the past decade, there have been many attempts to commercialize open source software. One common strategy has been to create services businesses, which offer consulting and support to users of open source. Another strategy has been to build hybrid businesses, which distribute open source platforms with proprietary add-ons, and which make money by licensing the add-ons.
A third strategy, and the focus of this chapter, is called dual licensing. Companies that use dual licensing provide a single software product under two different licenses. One license, which imposes open source terms, is available to a certain class of users. A second license, with proprietary terms, is available to others.
Business and Politics
This chapter is about business. Software is deep in the modern economy: it provides the mechanism for the flow of capital around the world, and it is itself a good that can be produced, bought, and sold. Whenever something interesting happens in the world of software, business leaders pay attention.
Open source is interesting. It enforces new rules for use and distribution of software products. It changes the economics of software production. It impacts the way that companies can capitalize on the software they control.
At the same time, though, open source has no business agenda. Open source is about freedom in the political sense. It is about peer review and scientific collaboration. Open source licenses take no position whatsoever on the profitability of business models. Open source is not antibusiness; it has no opinion.
Businesspeople, of course, have opinions on open source. Some years ago, when open source was still new to the business community, it was unfamiliar, and that unfamiliarity bred fear, confusion, and opposition. More recently, as quality open source software products have proven their value to all kinds of businesses, that opinion has shifted. Most businesspeople who have thought about open source at all are guardedly interested in it, and want to find ways to use it in their companies to be more efficient, to spend less, or to earn more.
An informed opinion on open source is important. Just as software is a powerful economic force, open source is a powerful force in the development and deployment of modern software systems. The Internet, including the World Wide Web, and a wide range of the services that run on it (for example, e-commerce sites such as Amazon.com; information retrieval services such as Google; and portals such as Yahoo!) exist because of open source software. Open source is a genie that is too big for its bottle. Now that it is out, it will not fit back in. If you do not put it to work for you, it is likely to wreak bad magic on your business.
My own opinion on open source is simple. It is one tool among many that can, when used sensibly, create business value. I run a business based on open source, but my agenda is commercial, not political. I understand the politics behind open source, and I appreciate and respect many smart people in the open source community. When I sit down at my desk, though, I am more interested in the difference between income and expenses on my profit and loss statement. To the extent that open source helps move that difference in the right direction, I care deeply about it.
The open source business strategy about which I know the most—and the focus of this chapter—is called dual licensing. Dual licensing is a way to make a single software product available under two different licenses. One is an open source license, and encourages sharing and collaboration. The other is a more conventional proprietary license, and permits secrecy and competition—which promote the creation of proprietary value. Dual licensing is a way to give a single product to open source users on open source terms, and to paying proprietary customers on conventional proprietary terms.
Open Source: Distribution Versus Development
Open source can include a distribution strategy or a development strategy. While people often think of the development strategy (many programmers working on a common project) when they think of high-profile projects like Linux, we are instead going to focus on the distribution strategy.
Open source is just a way to put product in many users' hands inexpensively. Dual- licensing businesses do not use collaborative development to build their products. In fact, as we will see, that production strategy is poisonous to dual-licensing businesses.
A dual-licensing business can take advantage of the cheap and ubiquitous Internet to distribute its products at low costs. Open source licensing promotes use at much lower cost, with much less friction, than an expensive marketing campaign could do. Dual-licensing businesses can distribute software to more people, more cheaply, than their proprietary competitors.
At the same time, dual licensing permits these businesses to generate revenue by licensing the software to certain users for a fee. Software licensing revenue is good revenue—because you can make and license a second copy of a piece of software for essentially no additional cost, businesses and the financial markets like licensing revenue. Selling support or services, by contrast, imposes new costs with every deal, because a business must have the capacity to answer the telephone for every new customer it captures. As a result, licensing-based businesses, including dual-licensing businesses, generally get higher valuations and can raise capital more cheaply than businesses based exclusively on services.
A Primer on Intellectual Property
Dual licensing, when you first encounter it, can seem like a parlor trick. How can I possibly charge money for software that you can get for free?
There is, in fact, no sleight of hand. Nobody gets tricked. Dual licensing requires some care, and the same diligence that most businesspeople bring to their jobs, but it turns out that governments around the world want businesses to be able to do this. They have constructed legal infrastructures that permit all sorts of businesses to make money with confidence. All it takes is to behave like a business and comply with the law.
Understanding the mechanism here is easier with some background in intellectual property law. Most software vendors make money by charging fees for an intangible product—algorithms and their implementations as expressed in computer code. All these businesses, including dual-licensing businesses, exist because of crucial legal concepts regarding intellectual property—concepts such as ownership and license grants.
Ownership of real property is easy to understand—my ball, your house, her island. Ownership of something intangible like the expression of ideas, is harder to understand. Over several centuries, governments have created rules about who may and may not make copies of artifacts like books and music. This "copyright" law balances the interests of the creator of a work—an author or a composer—with the interests of consumers who purchase those copies. Copyright law clarifies issues and resolves disputes among authors and readers. Copyright law has been adapted to apply to software, balancing the rights of software authors with those people who license and use their computer programs.
Copyright law worldwide generally says that the creator of an expression of an idea owns that expression. From the point of view of a computer programmer, this means that whoever writes a program owns the program. If the programmer copied parts of it from somewhere else, of course, he was not the creator of those parts, and he does not own them.
Unless the owner expressly assigns his rights to someone else, he owns his creation. Most employment agreements include just such an assignment provision, so the code a programmer writes for his job instantly becomes the property of his employer. The Free Software Foundation, an important organization in the free software movement, requires such assignment for any contribution to projects that it manages.
Without an explicit assignment, there can be many different owners of a large software product. This is exactly the case with many open source projects, including Linux. If 10 developers collaborate on an open source package, each of the 10 owns the pieces she produced. None of them owns the entire work.
Except in very rare circumstances, no one ever buys computer software. The person who created the work is its owner; a purchaser only buys certain rights to use the copy of the software in his possession. This distinction is critical to businesses that build software products. These businesses do not sell ownership. Instead, they sell licenses to the software, where "licenses" generally means a collection of rights to copy, run, and use the software product.
The owner is allowed, under the law, broad latitude to set conditions on use of the software. If someone wants a license to use the software, the owner can require that person to do any number of different things in exchange for the license.
Most proprietary software vendors require payment of a fee. This has been a remarkably successful business strategy for many decades, producing a number of billion-dollar software companies.
Open source software licensing does not require payment of a fee. The owners of open source software do impose other conditions on their open source licensees. Those conditions vary, depending on the open source license in use, but two broad categories are most common:
- Reciprocal licenses require that any recipient promise to contribute back any changes or additions to the software. Reciprocal licenses are coercive; they essentially enforce sharing. The most common reciprocal license in use is the GNU General Public License, or GPL.
- Academic licenses usually require very little—often, just acknowledgment of the original owner's work on the software. Academic licenses encourage reuse of other programmers' work by making it available on liberal terms. The most popular academic license in use is the Berkeley Software Distribution, or BSD, license.
In both the proprietary and open source cases, the owner of the software sets the conditions that others must meet to use the software.
The owner is allowed to set different conditions for different people. This same situation applies to real property: you might allow your brother to sleep in your spare bedroom for free, but probably would not let me do that on the same terms. At best, I could hope to pay you rent for use of the room. Likewise, the owner of a piece of software can grant different rights, on different terms, to different people.
This is common in proprietary software businesses. For example, if you buy a computer with an operating system and a word processor installed, you are most likely permitted to use those packages, but not to make copies of them for others to use. By contrast, the computer manufacturer is allowed to copy, install, and distribute both pieces of software to you and to others. The company that owns the operating system and word processor chooses to grant the computer manufacturer broader rights than you have, because the owner's goal is to make money in business, and creating a distribution channel that generates license fees is a good way to do that.
The fundamental point to remember is that open source licensing rests on the same foundation that proprietary software businesses use for their own licensing: copyright law and the notions of ownership and licensing that inform it. In both the proprietary and open source cases, the owner grants licenses to use the software under certain conditions.
One main benefit of being an owner is having the right to set those conditions.
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.
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 additions—which may well include the code for his own product—must 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.
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 licenses—and certainly all those used by dual-licensing businesses—are "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.
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.
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 do—they 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.
Dual licensing works. Using it, businesses can generate revenue based on license fees paid for copies of software. Because the public markets view this revenue as inherently lower margin than services revenue, dual-licensing companies have attractive valuations and can raise capital at parity with proprietary software vendors.
Every sustainable business must consistently earn more money than it spends. This is often hard.
One of the key considerations in designing a new business is the margin that the revenue stream can produce. Margin is, at base, the percentage of revenue that is profit. If you pay $100 to build a widget, and you pay a salesperson $100 to sell it, the widget costs you $200. If you charge $400 for it, you have an attractive margin—50%. If you charge $205 for it, you have a very thin margin—2.5%.
Most technology businesses sell licenses, or services, or a mixture of the two. For example, a company might license its product to customers, and might also sell consulting services to help customers integrate the product into existing IT infrastructures.
Licensing businesses generally have attractive margins. This is because, while it may cost $1 million in payroll to produce a new software program, the second copy of that program is essentially free. Having sunk the cost into building the product, the company can sell as many copies as it likes without paying the developers to start all over again. As a result, selling a new copy of an existing product really just requires paying the sales team that sells it.
Services businesses, by contrast, have much slimmer margins. This is because, to deliver the service, the business must have the people on the payroll who can do the work that is inherent in the services contract. Selling more consulting engagements requires that you hire more consultants. Thus, the costs that a services business incurs on every contract include not just the cost of selling it, but also the cost of fulfilling it.
Of course, very few companies are purely licensing businesses. Most provide at least customer support. However, building attractive margins is easier in a business with a significant licensing component.
Dual-licensing businesses offer two different revenue streams. Proprietary customers pay licensing fees, giving the business a high-margin licensing revenue stream. Both proprietary and open source users may choose to buy consulting or technical support, giving the business a lower-margin services revenue stream. This diversity in the revenue streams can allow the company to weather temporary slowdowns in either its licensing or its services businesses.
Over the past several years, the success of open source business models, and of dual- licensing models in particular, has caught the attention of the investment community. As investors have learned more about open source and dual licensing, they have begun to make investments—sometimes substantial investments—in new businesses. In addition, established companies have begun to look at open source as a strategic business advantage, and not just as a low-cost way to bring technology in- house. Major technology vendors have demonstrated their willingness to acquire open source businesses at prices that reward the principals and original investors in those businesses.
Venture capitalists and other sources of early-stage funding for companies look for a few key attributes in open source businesses.
First, of course, the company must have a credible, defensible business model. It is, generally, easier to raise money for a company that uses dual licensing, than for one planning to make money exclusively from services. The big risk for a new services business is that it will demonstrate the viability of a new services opportunity, and thus attract the attention of a large established services player. Popular open source packages have enormous installed bases. Businesses exist today that earn tens of millions of dollars supporting and training those users. That is enough money to interest even a large, established company.
The real problem with providing only services for an open source package is that the strategy is hard to defend against competitors. While it is true that the original authors of an open source package have an advantage in supporting it—after all, they know the most about how it works—freely available source code permits anyone else to learn the product internals and offer the same service.
Investors and acquirers are generally willing to pay less for a pure services business than for a licensing business, or for a business that combines the two sources of revenues. After all, costs grow in proportion to revenue growth. Every services sale requires staffing to meet the service commitment. Selling licenses for software, on the other hand, is much cheaper; making another copy of an existing product is free.
Second, investors look for open source packages with a solid market presence. The investor typically wants to see a track record of successful deployment to prove that a market exists. Thus, it is very hard to raise money to build a brand-new open source package from the ground up. Indeed, virtually all of the open source businesses funded in the past decade have tried to commercialize on the value of existing open source packages.
This creates a chicken-and-egg problem. The open source package must exist before it can be funded. Somehow, though, the package must get written in the first place. Generally, the open source packages that serve as the foundation for successful businesses were labors of love in the beginning, created by developers working in their spare time for free. Only when they succeeded in building a credible product could they raise money.
Third, and significantly, investors always look at the team in which they are asked to invest. As a rule, no investor will back an unbalanced organization—all engineering, or all marketing, for example. A fundable open source business must combine the technical expertise of a solid group of engineers with experienced management. In particular, the company must be properly staffed to market and sell the licenses or services that the business will offer. This point may seem obvious, but in practice, it is very hard to put together a solid team with the ability to make and execute a business plan that demands both solid product development and execution against a financial plan.
Once an open source business is successful in the market, it can choose to go in a number of directions.
If the business is generating profits, the owners may choose to continue to run it as a privately held company, earning a return on their effort and investment in the form of dividends. As a rule, venture-backed businesses do not have this option. The venture capital community wants to liquidate its investment at a profit within a few years of making the initial investment, and will press management to sell the company at some point. Absent that pressure, however, a strong, profitable, and growing business is a wonderful thing to own.
More commonly, small businesses are acquired by larger businesses, and folded into the bigger company. This rewards the original investors, as well as the principals who started the company and helped to make it successful. The acquisition will most often pay off in cash, stock in the bigger company, or a mixture of the two.
Established companies are willing to buy open source businesses for a variety of reasons. For example, open source technology is often ubiquitous in the market, and controlling that technology can give the big company important advantages over its competitors. In addition, an open source platform can create opportunities to build new proprietary product offerings that run on top of the open source, which creates new service and licensing revenue. The open source business's revenue may, on its own, be enough to capture the attention of the larger company.
The reasons that any particular acquirer chooses to buy any other business depend deeply on the peculiar circumstances of each, so there is no cookbook for building a company to sell. In general, though, a solid customer base, a track record of consistent growth, and a profitable revenue stream are good things.
The last way that small, privately held businesses transform themselves is to offer their stock for sale on the public markets. This is a much less common practice in today than it was six years earlier; a business must, in general, have very high revenues to make this transition. In addition, the demands on the management team in a publicly traded company are very different from, and in many ways more onerous than, the demands on a private company's team. The requirements for reporting financial information to the public markets and the need to manage the public investment community's expectations dramatically change the way that a company president works. As a result, many companies are forced to change their executive teams before offering themselves for sale on the public market.
One of the most important decisions in a dual-licensing business is what the terms will be for both the proprietary and the open source license. This issue is much bigger for the open source license, because that license is never negotiated. People simply download the software and accept the terms. As a result, a mistake in the open source terms is a mistake every single time the software is distributed.
Academic licenses are poorly suited to dual-licensing businesses, but reciprocal licenses generally work well. An academic license simply requires acknowledgment of the owner. Most rational businesspeople would much rather make that acknowledgment than hand over precious capital for use of software. A reciprocal license, by contrast, requires that the customer's own intellectual property be given away under an open source license. There is a very large population of potential customers who are more interested in protecting their intellectual property than in saving money.
As a result, the only kind of open source license that makes sense for a dual-licensing business is a very strong reciprocal license. The best example, of course, is the GNU GPL. Choosing the GPL gives you the benefit of the work already done by the Free Software Foundation, or FSF, in drafting the license and defining the key terms. In addition, the FSF has a strong vested interest in demonstrating the enforceability of the GPL, so, in the event of a dispute over unauthorized use of your dual-licensed product, you have access to a seasoned legal team that knows the subject well
It is almost certainly a mistake to try to draft your own open source license for a dual-licensing business. Doing so requires that you understand and apply the fundamental concepts of open source development and distribution in a new legal license. This is work you do not need to do if you choose an existing license. More importantly, writing a new license from scratch creates the opportunity to make bad mistakes. Finally, drafting a new license will require you to educate the open source and proprietary software business communities about the terms of your own license. This will create friction and inhibit adoption. You want developers concentrating on your software, not on your license.
Need and Pain
The interplay between the software product and its open source license is probably the single most important business issue for dual-licensing companies. The software product must create need in the market. Ideally, it will be so attractive to customers that they simply have to use it. At the same time, the open source license must cause enough pain that some users would rather pay money than endure the pain.
My company makes a product called Berkeley DB. It is an established product with a good reputation, but the only way for our customers to use it is to combine it with software they write themselves. That act of combination gives us leverage, because the resulting work is derived from our software, and we thus can dictate the terms under which the derivation must be licensed.
Our open source license requires that the entire work be released in open source form. Open source users, of course, can do this, but the requirement is poisonous to most proprietary vendors. Our dual-licensing strategy lets the proprietary customers pay for a proprietary license and keep their own intellectual property secret.
Linux is, once again, a good example of a product for which dual licensing would not work. Ignoring the ownership issues raised earlier, no customer needs to create and redistribute derivative versions of Linux. Customers simply want to install and use the operating system on their computers. None of those actions is forbidden by the GPL, so there is no pain.
Of course there are businesses making money distributing Linux, but they are doing so in different ways. Dual licensing works with only certain sorts of software, with very specific ownership characteristics.
Any vendor considering dual licensing must consider both technology and licensing when designing a business model. The software technology must be constructed so that users need to do something specific—for example, combine it with their own intellectual property and distribute the combined work to others—to use it. The open source license must make this activity painful to at least some customers with money. These customers must be willing to pay enough money to avoid that pain to make the business profitable.
On the other hand, the open source license must not be painful to the open source community, or it will undermine the benefits of the cheap and ubiquitous distribution channel that open source licensing provides. Open source users must experience only pleasure in their use of the software, or the product will fail to penetrate the market.
Measuring the Market
Businesspeople generally measure markets in terms of dollars—the amount of money that customers in the market will spend for a product or service. Dual-licensing businesses need a different metric, because they distribute their software to a combination of paying and nonpaying customers. The result is that a dual-licensing business can have a much larger installed base than a measure of dollars spent would suggest.
Dual-licensing businesses need to look at this issue pragmatically. Put bluntly, a dual- licensing business is never going to get all the money on the table. Some users would rather meet the open source terms than pay money for the software. A dual- licensing business must balance the size of its installed base, and the concomitant opportunity to sell more proprietary licenses, with the money that could be extracted by charging for every use.
The long-term goal of the business is to maximize profits and to grow. By foregoing some revenue in the short term, a dual-licensing business may make its product ubiquitous, which creates additional long-term opportunity. Though you might never get all the money on the table, you can find yourself sitting at a much bigger table this way.
There are two other benefits to a large installed base, even if not everyone in it pays a license fee.One, noted earlier, is that the earth is scorched for competitors: the only way to compete on price with a free product is to pay people to use a competitive one. This is an expensive way to capture customers.
The other, of course, is the opportunity to sell services independently of license fees. A large installed base may be willing to pay for consulting and support, even if it is not willing to pay for the software. Generally, dual-licensing businesses offer these services and book revenue profitably as a result. As a rule, however, dual licensing is more valuable for the license fees that proprietary users pay than for the service fees that open source users are willing to pay.
Because open source software is widely available, it is easy for software pirates to make and distribute copies in ways that violate the open source license for the code. Significantly, it is easy for a user to download the software under an open source license, and then to use it in ways that only a paid proprietary license would permit.
Piracy is not, of course, a problem unique to open source or dual-licensing companies. Every software vendor—indeed, every software developer who distributes a product—runs the risk that unscrupulous users will pirate copies of the product. Individual vendors and umbrella organizations like the Business Software Alliance battle the problem continually.
Piracy is a very real business problem for dual-licensing vendors. The two lines of defense are diligence in protecting intellectual property rights, and consistent and clear explanations of the terms under which the software is distributed.
Diligence in protecting intellectual property rights is relatively simple. Anytime a dual-licensing vendor learns of a misappropriation of its software, it must pursue and resolve the issue. This is no different from the rules that apply to a proprietary software vendor, of course.
Consistent and clear messaging on the license terms is equally important. Open source licensing is now generally well understood by the software industry. By emphasizing the conditions that apply to open source use, and making clear the difference between its paid and proprietary licenses, a dual-licensing vendor can educate its users and capture business before problems crop up.
In general, no responsible business or consumer wants to misappropriate the intellectual property of another. The penalties are large, the risks are unacceptable, and it simply is not fair. Most consumers of software want to obey the law.
Dual-licensing vendors are in exactly the same position as purely proprietary vendors. Digital distribution means that copying is easy. There are pirated copies of both proprietary and dual-licensed software in the world. Vendors of both have the same law behind them and the same recourse against pirates.
The Social Contract
Open source is much more than an ingredient in a business model, of course. The movement predates the dual-licensing model by decades, and its long history has produced a complex and nuanced present. Any business that proposes to use open source technology, including dual-licensing businesses, must understand and participate in the open source movement as it exists today.
The open source community generally cares a great deal about reputation; companies, as well as individuals, gain status by being smart and by contributing to the good of the community. Contribution certainly includes developing open source technology for use by others, and any dual-licensing business will do that. Contribution can also mean, for example, promoting and explaining open source technology in the press and at industry meetings—a task for which businesses are often better suited than individuals—and supporting worthy open source projects with staff time and money.
It is unusual in business for an outside group that pays a company no money and that has no legislative authority to have as much influence over a business and its policies as the general open source community does over open source businesses. If a company alienates the open source community, the main advantages of open source distribution—ubiquity and a large installed base—can disappear in a flood of bad press and ill will on developer discussion lists. Executives at dual-licensing businesses must speak clearly to their open source constituencies. They must show the community the respect it deserves in order to earn the community's respect in return.
Besides merely making friends with the open source community, dual-licensing businesses must pay attention to issues that are unique to the business model.
An unwritten social contract among open source developers says that the community generally will produce software that benefits the community most. This is in some sense driven by Darwin—the people who write open source code work on the problems they consider most important, so if there is widespread pain around a particular issue, there will be widespread attention to addressing it.
The social contract, of course, is not perfect. For example, many open source projects are more poorly documented than their proprietary competitors, because very few programmers enjoy writing documentation, and few will do it without being paid. While proprietary enterprise software is not always more polished than open source, it is generally the case that the drudgery in proprietary development gets more attention than it does in open source projects. A programmer working as a volunteer often lacks the patience to do the exhaustive testing and debugging, interface cleanup, and so on, that commercial licensees of software have come to expect.
The introduction of companies focused on profits into this mix alters the social contract of open source. The change is, in some respects, for the better, but it is a change nonetheless.
Businesses driven by profits will invest to maximize those profits. A large customer willing to pay a significant price for a new feature or for changed behavior in a product will get more attention from a business than will a large number of nonpaying users who all want some different feature or behavior. In business, customers vote with their money. In pure open source, contributors vote with their programming time.
A dual-licensing business will, and should, pay attention to the requirements of its paying customers. The business needs to balance the needs of its paying customers with the needs of the nonpaying open source user community. After all, the company does not want to alienate its open source users and thereby lose the benefits of its open source distribution.
As a rule, this issue requires attention, but seldom causes real problems. Paying customers are usually interested in speed, reliability, or enhancements that make a product more powerful. Those improvements are all useful and interesting to open source users as well, so it seldom happens that the open source community loses and the paying customer wins.
From the point of view of the paying customer, the ability of money to influence the product roadmap is actually a benefit. Many companies considering adopting open source technology are concerned that they have no way to influence the development community to solve real business problems for them. Because dual-licensing companies care about income and profits, customers know that they can get the vendor's attention the old-fashioned way: by pulling out a checkbook.
Trends and the Future
Dual licensing is an innovative strategy that combines open source distribution with proprietary licensing. The combination confers competitive advantages on businesses that use it. These advantages include a low-cost distribution channel, powerful product marketing, and a high-margin, scalable revenue stream.
Of course, dual licensing is just one tool that businesspeople can use to build sustainable enterprises in a world where technology and economic forces are in constant change. The rest of this chapter examines dual licensing in that larger context.
The flow of capital and information across borders has transformed the world from a collection of economic islands into a more integrated global economy. That trend will surely continue, and will likely accelerate, over the next decade. At the same time, security concerns, and particularly worries about terrorism, create a strong political incentive to encourage the development of a prosperous middle class with an economic stake in the future in emerging economies.
Worldwide economic development is necessarily influenced by information technology. Leaders of emerging nations are clearly interested in building clean, sustainable IT industries. Doing so requires a significant investment in education, but also an investment in enabling technology.
Dual licensing provides a way for nascent knowledge economies to grow. Because dual-licensed software is available for use at no charge under open source terms, emerging businesses can preserve precious capital by choosing to comply with the terms of the open source license.
China is an instructive example. In 2004, the Chinese government announced its intention to invest in the development of a version of Linux tailored for use in the country, with language and character set support and other new features. The economic advantage conferred by a low- or no-cost operating system in a country where an enormous number of computers will be installed soon is obvious. Between 2005 and 2010, China is likely to become the world's largest consumer and producer of open source software. Consumption will increase earlier, and faster, than production. Demand for high-quality open source and dual-licensed products will be very high.
Although there is little or no short-term revenue for dual-licensing businesses here, they do establish a long-term competitive advantage. As these small businesses in emerging economies grow, and as they build value in expertise or new hardware and software products, they can choose to pay some of their new capital for the more permissive terms of the proprietary license. The cost of switching encourages customers to stay with the product that they know, and the one built into their own products.
This same strategy applies to developed economies. Software vendors are generally interested in the education market, in part because they want the next generation of software consumers trained to use their products. Many vendors encourage university researchers and students to use their products so that the students will prefer those products when they graduate and eventually recommend software purchases to their new employers.
Dual-license vendors have an advantage in both cases, relative to proprietary vendors. Because the open source license terms permit use at no charge under reasonable conditions, individual business owners, as well as researchers and students, can choose the open source software easily. They do not need to negotiate a special low- or no-cost introductory license to use the product. There is much less friction in the distribution of open source software than in most proprietary software distribution, and the lower friction translates into higher adoption.
Dual licensing is, at base, the combination of a venerable business strategy—licensing software for money—with a relatively new open source distribution strategy. This combination is interesting and valuable on its own, but it is by no means the only such combination that is possible.
The global Internet makes the distribution of content much cheaper and easier than it ever was before. At the same time, it eliminates barriers to sharing among widely dispersed individuals and companies. The effect is to create new opportunities for the collaborative creation of intellectual property.
Some examples of this collaborative development were all but unknown just a few years ago. Weblogs, or blogs, are common today. They have emerged as an alternative source for news and information, replacing older media such as newspapers and radio, especially for fast-breaking stories. Similarly, the publication and production of scientific journals is changing. Single-vendor control over high-profile journals, and the vendor's ability to dictate pricing to the market, is eroding because researchers can collaborate and publish their research online more easily than ever before. Finally, some web sites encourage user contributions to make themselves more valuable to visitors. An excellent example is the book and other product reviews on Amazon.com. Amazon's visitors share their reviews with one another because they benefit from that sharing, but Amazon itself gains an enormous advantage because of the depth and breadth of those reviews.
In all three of these cases, old-fashioned ideas, like news distribution, journal publication, and product reviews, have been transformed by the open, collaborative processes that the Internet encourages. Licensing is as much an issue here as in software distribution—ownership of the content, and the right to distribute it online, must be considered carefully.
Collaboration and open distribution continue to transform the way that businesses operate. That transformation necessarily damages some established businesses, especially those where a middleman controlled the flow of goods or information, and was able to extract a fee from the flow. The Internet allows individuals to bypass that middleman—the well-known "disintermediation" strategy—and to share and publish on their own.
Any new business built on a disintermediation strategy must consider the law. Unlawful distribution of copyrighted music files is theft, not sharing, but that fact alone does not mean that the existing music retailing industry makes sense in a world with cheap ubiquitous bandwidth. The next generation of businesses must find ways to use the legal system to protect intellectual property, even while they take advantage of the powerful collaborative properties of the global Internet.
The Future of Software
Open source has transformed the way that software is produced. Now, with dual licensing, open source is changing the way that proprietary software is distributed.
Dual licensing will never replace either pure proprietary or pure open source strategies. There are compelling reasons for both to exist.
Purely proprietary distribution allows companies to invest significantly in new development and to be rewarded for that investment. Particularly at the edge of information technology, where the newest products and services are built, businesses will use proprietary licensing to protect their competitive position and to extract maximum value from their efforts.
Purely open source development and distribution, on the other hand, reduces costs of core infrastructure for consumers, and powerful market forces encourage investment in that cost reduction. Open source has been most successful in those sectors of the market where technology is mature and stable—operating systems, databases, web servers, and middleware. This is not to say that open source development is not innovative, but its impact has been largest in the cases where it has commoditized products in mature markets.
The net effect of open source distribution, from the point of view of the consumer, is to reduce the total cost of software licensing. Dual licensing does nothing to reverse this trend; dual-licensed software will exert downward price pressure on established markets just as purely open source software does, though the net reduction in costs will be lower since some consumers continue to pay for software licenses.
Dual licensing will continue to grow in popularity as new and established businesses apply the strategy to new opportunities. Competitive pressure ensures that businesses will look for ways to gain advantages over one another, and building a hybrid business offers advantages in many cases. Other novel hybrid strategies will, no doubt, appear in the future.
- ↑ The bodies of law dealing with trade secrets and patents are also both important to businesses, but are beyond the scope of this discussion. Patents in particular complicate open source software development and distribution, and are something of a lightning rod in the debate between proponents and opponents of open source.