Let there be no doubt about it: the open source model is changing the way people develop, acquire, implement, and maintain software. In 2007, Gartner declared open source software “the biggest disruptor the software industry [Gartner] has ever seen and [Gartner] postulated it will eventually result in cheaper software and new business models.” They stated that open source products accounted for a 13 percent share of the $92.7 billion software market in 2006, but should account for 27 percent of the market in 2011 when revenue is expected to be $169.2 billion, according to Gartner research.
Today, all developers, entrepreneurs, and users of software need to understand open source, not least because, by dramatically speeding up development, improving quality, and reducing the cost of marketing and sales, it represents a paradigm shift in the development and distribution of software. The use of open source software is becoming ubiquitous: for example, the Apache web server is used by more than 60 percent of web servers and the Linux operating system is used on a wide variety of products ranging from digital televisions to computers.
Although the press has paid much attention to “pure” open source companies, such as JBoss or Monta Vista, many companies are adopting “hybrid” business models which include both open source and proprietary software. In 2007, major proprietary software companies announced the “open sourcing” of some of their products: Adobe “open sourced” its Flex tool for Flash programming and Yahoo “open sourced” its Flickr upload tool. For software developers, open source software provides a significant opportunity to speed development and enhance functionality. Therefore, virtually all software companies that don’t closely manage their development and IT departments may have open source software in their products. The open source business model, even more that proprietary software business model, requires careful attention to legal issues because many such issues remain open.
Although some companies still openly express skepticism about the viability of the open source model, open source products are used by such major companies as IBM, HP, Dell, DaimlerChrysler, and E*TRADE. Furthermore, open source companies have become quite popular in the venture capital community. Major venture capital firms such as Kleiner Perkins, NEA, Draper Fisher & Jurvetson, and Walden International have invested in one or more open source companies. In 2005, venture capitalists invested over $120 million (some reports claim as much as $400 million) in open source companies. Although some investors have expressed concern about the availability of “exits” for open source companies, these concerns have been laid to rest in the last year including Yahoo’s acquisition of Zimbra, Oracle’s acquisition of Sleepycat, IBM’s acquisition of Gluecode, Citrix’s acquisition of Xensource, Red Hat’s acquisition of JBoss and Sun’s acquisition of MySQL. Sun Microsystems has shifted to an open source business model, making both its Solaris operating system and Java software available under open source licenses.
However, the uncontrolled use of open source software can lead to serious problems for companies. For example, IBM reduced the purchase price for Think Dynamics by 30 percent due to uncertainties arising from the use of open source. The use of open source software needs to be managed carefully. One reason for this is the many legal uncertainties that surround its use. None of the more than 50 licenses approved by the Open Source Initiative as being “open source” have been interpreted by United States courts; thus, many issues regarding use of open source remain uncertain. For example, the General Public License Version 2 (GPLv2), the most commonly used open source license, extends to all “derivative works” of the original program. A “derivative work” is a term with special meaning in copyright law, but its definition for software varies in different courts in the United States. The definition of derivative work becomes very important because the GPLv2 requires that if a company distributes GPLv2 licensed software, it must include the source code (as well as the object code) of all software, as well as the “derivative works” of such software. The Free Software Foundation has defined derivative works to include “dynamically linked” software. The GPLv2 further requires that all licensees be given the right to modify and redistribute such software without charge. Another major concern for many companies is that the GPLv2 terminates immediately upon any breach of its terms rather than the more common approach of providing a thirty day (or longer) period to “cure” any such breach. This immediate termination is particularly troubling because of the many uncertainties in the GPLv2. The new version, General Public License Version 3 (“GPLv3″), has corrected many of these problems, for example GPLv3 includes a “cure” period.
Another way to look at this issue is to note that profitable software development requires close management of open source software. For example, after Cisco bought Linksys for $500 million, the Free Software Foundation approached Cisco claiming that elements of Linksys products should be made available in source code form because open source code licensed under the GPLv2 was included in the product. Neither Cisco nor Linksys were aware of this at the time of acquisition. The Free Software Foundation, the developer and enforcer of the GPLv2, initially insisted that Cisco make the entire source code of the Linksys operating system available under the GPLv2. Such a result would have dramatically reduced the value of Linksys because the source code of the Linksys products would have been available at no charge to any licensee. However, Cisco and the Free Software Foundation came to an agreement that the open source software was limited to a single driver, and Cisco agreed to distribute that driver under the GPLv2. Recently, the Free Software Foundation has filed three lawsuits to enforce the GPLv2, including a suit against Verizon.
Both software developers and software users should avoid such problems by adopting an open source use policy. An open source use policy should address the following issues:
- Use of open source components in products for third parties
- Use of open source for internal purposes
- Approved usage models
- Implementation of policy by industry experts or outsourced teams
- Permitted/forbidden open source licenses
- Rules for contribution by employees to open source projects
- Use of commercial products (Black Duck/Palmida/HP FOSSology) to audit use of open source code
These policies may range from simple ones for startups to elaborate 60-page documents for large companies. A company’s open source policy is frequently implemented by committees which include technical, business development, and legal representatives who make the final determinations. One large company reviewed 1,500 potential uses of open source products in an 18-month period (they approved all but 10 uses).
As noted above, many companies who do not consider themselves “open source” are nevertheless incorporating elements of open source distribution and development into their core business model. The business model for software products can range from the traditional “services only” model, such as Collabnet, to “commercial” open source products such as SugarCRM. A common commercial open source model provides for distribution of the product under an open source license as well as distribution of a version under traditional commercial terms, including a performance warranty and infringement indemnity. The open source business model is very powerful because it enables a company to leverage its open source “community” of developers to review the source code and discover and correct bugs much more rapidly, in addition to the community contributing to new code which provides additional functionality. In addition, the open source model allows customers to “try before you buy,” which dramatically decreases the company’s costs for sales and sales personnel. Many open source companies have thousands or tens of thousands of downloads each month.
The relationship between a company and the open source community is unique to the business model, and it is essential. One radical difference between the open source business model and the proprietary business model is that the open source model requires that the software code be accessible to individual programmers: it should be “lightly” coupled or integrated so the members of the community can focus on a part of the product and not be forced to use large amounts of software with little value to them. Software programs that are tightly coupled or “non-modular” in design are not likely to be accepted by the open source community.
In addition, the open source community is very sensitive to companies that attempt to claim “open source” status without “giving back to the community.” A number of companies have claimed to be open source but they don’t make their source code available and/or don’t use an Open Source Initiative approved license: these companies have been uniformly unsuccessful in developing communities or have lost any community support. When a company loses a good relationship with the community, the result is sparse contribution by the community. Without community support, companies will lose the leverage that makes the open source business model so powerful.
In the worst case, failure to properly manage open source can result in the “forking” of code into two separate incompatible products. Forking is a problem particular to the open source business model. Forking is possible only because of the availability of source code, and it can destroy a product. As an illustration the content management project Mambo — founded by a commercial company, Miro — split into two groups, Mambo and Joomla, because Miro tried to exert too much control over the community.
The adoption of an open source business model also requires a different approach to an intellectual property strategy. Providing the software under an open source license means the trade secrets in the product will be lost and copyright will be much less important because of the scope of open source licenses. Thus, open source companies must depend much more on trademark and patent rights to maximize their value.
Even those software companies that do not incorporate components of open source into their business model need to understand these issues because both customers and potential acquirers are becoming much more sensitive to the use of open source software. Many large Silicon Valley companies have a specific provision in their development agreements which requires the description of, and advance approval of, all use of open source software. In fact, in one case, the provision relating to open source software has the title “Infectious Software.” Many sophisticated acquirers now have a separate “due diligence process” for open source software. The results of such due diligence regarding open source software can result in a reduction in purchase price or even termination of the transaction. Since acquisitions are very intense transactions, the worst result for a software company is to discover the use of open source software during the due diligence: when that happens, the solution or remediation must be found quickly, which limits options. The best approach is to adopt an appropriate open source use policy and to meticulously use commercial products to audit the implementation of the policy.
Companies that are users of software must also be careful about their use of open source software. The use can lead to problems if “blended” with proprietary software: as stated earlier, the breach of many open source licenses results in automatic termination without the ability to “cure” the breach. And many software “users” also distribute software to their customers, thus triggering the obligations regarding distribution under traditional open source licenses. Thus, many large software users also have open source use policies.
Open source provides many great opportunities, but it requires careful research, understanding and thoughtful management.
