Open Source Goes Mainstream: How to Manage the Risk

In recent years, numerous articles have been published in legal journals warning of the inherent risks of using open source code in the development of software ' the fear of pirated code, the possible threat of infringement claims, the “viral” effect of the redistribution provisions of the open source license on proprietary code, just to mention a few. Arguments that such risks are merely academic were trounced when SCO Group launched an infringement claim against IBM and its customers. (SCO Group sued IBM, alleging that IBM's Linux operating systems contained pirated UNIX code and related trade secrets allegedly owned by SCO. SCO has also sued two of IBM's major customers.)

Notwithstanding the dire warnings from lawyers and risk managers alike, companies continue to use open source code for their internal use, and to develop products to be sold or licensed to customers. Computer Weekly reported that 46% of firms surveyed by Forrester Research currently use open source, and another 14% plan to use it within the next 12 months. See, Computer Weekly, June 15, 2004, page 22. The acceptance of open source as a viable means to build sophisticated operating systems is also growing in the public sector. See, eWeek, eWeek.com, June 14, 2004. A recent article published in The Economist states: “That `open source' is a good way to make software is beyond question”, and suggests that open source represents a “new post-capitalist economic model” “Beyond Capitalism,” The Economist, June 12, 2004. Larger technology firms such as IBM, Sun, Apple and Novell have even jumped on the bandwagon by “open sourcing” some of their products.

The Benefits of Open Source

The most oft cited benefit of open source to developers is its relatively low cost. Once an open source program has been created and distributed, each user has the right to use, copy, distribute and/or modify the source code, in contrast to commercial software licenses, which grant access only to the object code of the software, limit the scope of use, and restrict the user's ability to modify and redistribute the code. Most open source license agreements also require that improvements created by modifying the code must be redistributed in source code form so that all users can benefit from improvements made by others.

This “free” modification and distribution model means that software acquisition and development comes at a marginal (financial) cost. Savings are realized because additional licenses (and license fees) are not required as the installation grows. Malcolm Wheatley, “The Myths of Open Source”, CIO Magazine, March 1, 2004, page 3. Users of open source often cite other benefits of open source, such as the existence of multiple support resources and greater customizability.

The Risks of Open Source

The most significant risks associated with open source code fall into two categories: 1) inheriting previously existing tainted code; and 2) the “viral” or “forced sharing” provisions of certain open source licenses that can raise significant concerns if a developer plans to modify the open source, or combine it with any proprietary software.

Tainted Code. Since open source code can be freely used, modified and distributed by those who have access to it, there is the risk that any version of the code is tainted; specifically, it may contain pirated code or otherwise infringe the intellectual property rights of a third party. In typical commercial licensing scenarios, this risk is allocated by the parties in the license agreement. If a licensee is paying a reasonable amount of money for the use of the software, it will negotiate certain warranties and/or indemnification rights to protect it against such infringement claims. In the case of most open source licenses, no such warranties or indemnification rights exist, although, more recently, some open source licensors have indicated a willingness to indemnify customers for infringement claims. A company that intends to use open source software only for its internal use, may reasonably determine that the risk of an infringement claim for the use it is contemplating is low or, in any event, acceptable in light of perceived cost savings. The concern is greater, however, when the intended use of the open source includes redistribution of that code to customers for a fee, together with proprietary software (even without modification to that open source). To the extent that such customers want the benefit of commercially reasonable warranties and indemnification rights, the developer that uses open source will be responsible for any problems attributable to the open source software programs, as well as its own proprietary code.

The GPL and Modifications. Although not all open source license agreements are created equal, the GNU General Public Licensee (GPL) and the Lesser GNU Public License (LGPL), which govern the use of Linux and other open source programs, contain the troublesome “forced sharing” provisions. These licenses provide that any modifications made to source code licensed under the GPL or the LGPL must be made available to others at no cost. Although the licensee is not required to distribute these modifications if the software is only used internally, if any modifications are distributed to a customer, the entire work, as modified, must be distributed in source code under the same terms as the original open source license. See, www.gnu.org/licenses/gpl.html. Some commentators interpret this to mean that if developers bundle and distribute their own proprietary software code with modified open source licensed under the GPL or the LPGL, the developer forfeits its trade secret rights to its own proprietary software code.

These licenses set out some exceptions to the redistribution requirement, but they are ambiguous and generally unhelpful. For example, works would not be subject to this requirement if they “can be reasonably considered independent and separate works,” but the licenses provide no clear definition of what constitutes “independent and separate works.” The GPL also states that an “aggregation” of the open source with proprietary software that is not based on the open source (eg, both programs merely appear on the same disk) is not subject to the provisions. Whether a court would find that the proprietary software is “independent” or part of an “aggregation” will likely depend on a number of technical factors, such as how closely the programs interact, how they are linked, what kind of information is exchanged, whether the proprietary code has application apart from the open source code, and how the proprietary software loads with the open source. In addition, it is not clear whether a proprietary software executable that dynamically links to an open source library would be subject to the GPL, and there have been no clear court decisions to resolve this issue.

Options for Working with Open Source

Though the risks of using open source remain ever present, open source seems to be here to stay. That said, what strategies can be adopted to maximize the benefits of the use of open source, and minimize the risk of becoming involved in protracted and expensive infringement litigation?

Abstinence. Although recent trends indicate that this is becoming a less desirable response to open source, for some companies, simply deciding not to use open source code can be the right decision. A high profile company with deep pockets may be susceptible to an infringement claim if it allegedly fails to properly distribute an open source program in accordance with the terms of the GPL, LGPL or other similar license, and any customers using the software could be implicated. The costs are real and significant. An infringer could be subject to injunctive relief and liable for damages equal to the plaintiff's losses and the defendant's profits, attorney's fees and costs and possible statutory damages. Moreover, if a customer is sued in connection with its use of the infringing software, the infringing licensor most likely would also be responsible for indemnifying that customer against such claims.

Adopt an Open Source Policy. For those companies that will use open source in the development of software, adopting a coherent and consistent open source policy is strongly advisable. An open source policy should:

• Set parameters for the in-licensing of any open source software including identifying acceptable open source programs and approved vendors of acceptable open source programs ' factors to consider might include the willingness of a financially healthy provider to offer warranties or indemnification in case of a problem;
• Determine how the open source will be used, including specifically establishing a process (that includes the involvement of both business and legal representatives) to determine when, if ever, open source may be modified or distributed to a customer; and
• Establish a process (also involving both business and legal representatives) for determining how to develop, link, market and distribute to customers software products that use or incorporate open source software so that homegrown code that can be harmlessly included with open source code is so included, but proprietary software as to which there are sound business reasons to keep the code away from the open source regime does not become inadvertently subject to the “forced sharing” provisions of the GPL and LGPL.

Establishing an open source policy will also help ensure compliance with the terms of the open source licenses, such as the inclusion of disclaimers of warranties and copyright notice requirements. In order to comply with certain open source licenses, a company's standard forms of license agreements and packaging may need to be revised and updated with each new piece of open source aggregated or bundled with proprietary software.

Prepare for Litigation. If a company elects to use, modify and redistribute open source either alone or in conjunction with its own software, it must be with the understanding that it is willing to spend the money to defend a position that its bundled software is not subject to the redistribution provisions of the GPL, and the company should, prior to any distribution, work with its lawyers to determine a strategy for out-licensing the software in a manner that is consistent with that position. The out-licensing strategy will depend on how the open source is actually being used. For example, where open source and proprietary components are discrete, a licensor may require customers to obtain their own licenses to the open source software or, if that is not desirable or commercially feasible, ensure that its own license agreements make it clear that open source software is licensed to the customer pursuant to the terms of a separate open source license and provide direct access to that license.

Prepare for Acquisition or other Liquidity Event. The foregoing strategies are essential to a company not only for maintaining its licensing strategy, but also in preparation for a sale, merger or financing. Sophisticated purchasers and investors now include open source as one of their due diligence items. Targets can expect to receive inquiries concerning the use of open source in connection with internal operating systems, and with any software or products licensed or sold to customers. Purchasers and investors often want to see detailed inventories of open source products used in the business, including copies of license agreements, and specific disclosures and representations concerning the use, modification and distribution of any open source software. Most open source license agreements also contain restrictions on the transfer or assignment of the license agreement. If the software license cannot be assigned to the potential acquirer, it may have to obtain those licenses on its own behalf, which will result in increased transaction costs. The response to these inquiries can have a direct impact on the valuation of the software and intellectual property assets of a company, as well as the perceived risk associated with the deal. For example, the failure to adequately respond to these inquiries can increase the likelihood that a purchaser will require onerous indemnification or holdback provisions in connection with an acquisition. A coherent and responsive open source policy can create a more efficient due diligence exercise, and eliminate the element of surprise.

Open source and commercial software licensing models, each at opposite ends of the licensing spectrum, appear to be moving towards each other. Large technology suppliers are adopting limited open source programs for their products, and open source providers are moving toward more mainstream commercial terms in connection with open source, such as infringement indemnification and the provision of support services. It is still critical, however, that businesses have a clear understanding of what open licensing is, and what the underlying license agreements both require and imply, before utilizing open source in any internal systems, and particularly before modifying open source and distributing it to downstream users.

In recent years, numerous articles have been published in legal journals warning of the inherent risks of using open source code in the development of software ' the fear of pirated code, the possible threat of infringement claims, the “viral” effect of the redistribution provisions of the open source license on proprietary code, just to mention a few. Arguments that such risks are merely academic were trounced when SCO Group launched an infringement claim against IBM and its customers. (SCO Group sued IBM, alleging that IBM's Linux operating systems contained pirated UNIX code and related trade secrets allegedly owned by SCO. SCO has also sued two of IBM's major customers.)

Notwithstanding the dire warnings from lawyers and risk managers alike, companies continue to use open source code for their internal use, and to develop products to be sold or licensed to customers. Computer Weekly reported that 46% of firms surveyed by Forrester Research currently use open source, and another 14% plan to use it within the next 12 months. See, Computer Weekly, June 15, 2004, page 22. The acceptance of open source as a viable means to build sophisticated operating systems is also growing in the public sector. See, eWeek, eWeek.com, June 14, 2004. A recent article published in The Economist states: “That `open source' is a good way to make software is beyond question”, and suggests that open source represents a “new post-capitalist economic model” “Beyond Capitalism,” The Economist, June 12, 2004. Larger technology firms such as IBM, Sun, Apple and Novell have even jumped on the bandwagon by “open sourcing” some of their products.

The Benefits of Open Source

The most oft cited benefit of open source to developers is its relatively low cost. Once an open source program has been created and distributed, each user has the right to use, copy, distribute and/or modify the source code, in contrast to commercial software licenses, which grant access only to the object code of the software, limit the scope of use, and restrict the user's ability to modify and redistribute the code. Most open source license agreements also require that improvements created by modifying the code must be redistributed in source code form so that all users can benefit from improvements made by others.

This “free” modification and distribution model means that software acquisition and development comes at a marginal (financial) cost. Savings are realized because additional licenses (and license fees) are not required as the installation grows. Malcolm Wheatley, “The Myths of Open Source”, CIO Magazine, March 1, 2004, page 3. Users of open source often cite other benefits of open source, such as the existence of multiple support resources and greater customizability.

The Risks of Open Source

The most significant risks associated with open source code fall into two categories: 1) inheriting previously existing tainted code; and 2) the “viral” or “forced sharing” provisions of certain open source licenses that can raise significant concerns if a developer plans to modify the open source, or combine it with any proprietary software.

Tainted Code. Since open source code can be freely used, modified and distributed by those who have access to it, there is the risk that any version of the code is tainted; specifically, it may contain pirated code or otherwise infringe the intellectual property rights of a third party. In typical commercial licensing scenarios, this risk is allocated by the parties in the license agreement. If a licensee is paying a reasonable amount of money for the use of the software, it will negotiate certain warranties and/or indemnification rights to protect it against such infringement claims. In the case of most open source licenses, no such warranties or indemnification rights exist, although, more recently, some open source licensors have indicated a willingness to indemnify customers for infringement claims. A company that intends to use open source software only for its internal use, may reasonably determine that the risk of an infringement claim for the use it is contemplating is low or, in any event, acceptable in light of perceived cost savings. The concern is greater, however, when the intended use of the open source includes redistribution of that code to customers for a fee, together with proprietary software (even without modification to that open source). To the extent that such customers want the benefit of commercially reasonable warranties and indemnification rights, the developer that uses open source will be responsible for any problems attributable to the open source software programs, as well as its own proprietary code.

The GPL and Modifications. Although not all open source license agreements are created equal, the GNU General Public Licensee (GPL) and the Lesser GNU Public License (LGPL), which govern the use of Linux and other open source programs, contain the troublesome “forced sharing” provisions. These licenses provide that any modifications made to source code licensed under the GPL or the LGPL must be made available to others at no cost. Although the licensee is not required to distribute these modifications if the software is only used internally, if any modifications are distributed to a customer, the entire work, as modified, must be distributed in source code under the same terms as the original open source license. See, www.gnu.org/licenses/gpl.html. Some commentators interpret this to mean that if developers bundle and distribute their own proprietary software code with modified open source licensed under the GPL or the LPGL, the developer forfeits its trade secret rights to its own proprietary software code.

These licenses set out some exceptions to the redistribution requirement, but they are ambiguous and generally unhelpful. For example, works would not be subject to this requirement if they “can be reasonably considered independent and separate works,” but the licenses provide no clear definition of what constitutes “independent and separate works.” The GPL also states that an “aggregation” of the open source with proprietary software that is not based on the open source (eg, both programs merely appear on the same disk) is not subject to the provisions. Whether a court would find that the proprietary software is “independent” or part of an “aggregation” will likely depend on a number of technical factors, such as how closely the programs interact, how they are linked, what kind of information is exchanged, whether the proprietary code has application apart from the open source code, and how the proprietary software loads with the open source. In addition, it is not clear whether a proprietary software executable that dynamically links to an open source library would be subject to the GPL, and there have been no clear court decisions to resolve this issue.

Options for Working with Open Source

Though the risks of using open source remain ever present, open source seems to be here to stay. That said, what strategies can be adopted to maximize the benefits of the use of open source, and minimize the risk of becoming involved in protracted and expensive infringement litigation?

Abstinence. Although recent trends indicate that this is becoming a less desirable response to open source, for some companies, simply deciding not to use open source code can be the right decision. A high profile company with deep pockets may be susceptible to an infringement claim if it allegedly fails to properly distribute an open source program in accordance with the terms of the GPL, LGPL or other similar license, and any customers using the software could be implicated. The costs are real and significant. An infringer could be subject to injunctive relief and liable for damages equal to the plaintiff's losses and the defendant's profits, attorney's fees and costs and possible statutory damages. Moreover, if a customer is sued in connection with its use of the infringing software, the infringing licensor most likely would also be responsible for indemnifying that customer against such claims.

Adopt an Open Source Policy. For those companies that will use open source in the development of software, adopting a coherent and consistent open source policy is strongly advisable. An open source policy should:

• Set parameters for the in-licensing of any open source software including identifying acceptable open source programs and approved vendors of acceptable open source programs ' factors to consider might include the willingness of a financially healthy provider to offer warranties or indemnification in case of a problem;
• Determine how the open source will be used, including specifically establishing a process (that includes the involvement of both business and legal representatives) to determine when, if ever, open source may be modified or distributed to a customer; and
• Establish a process (also involving both business and legal representatives) for determining how to develop, link, market and distribute to customers software products that use or incorporate open source software so that homegrown code that can be harmlessly included with open source code is so included, but proprietary software as to which there are sound business reasons to keep the code away from the open source regime does not become inadvertently subject to the “forced sharing” provisions of the GPL and LGPL.

Establishing an open source policy will also help ensure compliance with the terms of the open source licenses, such as the inclusion of disclaimers of warranties and copyright notice requirements. In order to comply with certain open source licenses, a company's standard forms of license agreements and packaging may need to be revised and updated with each new piece of open source aggregated or bundled with proprietary software.

Prepare for Litigation. If a company elects to use, modify and redistribute open source either alone or in conjunction with its own software, it must be with the understanding that it is willing to spend the money to defend a position that its bundled software is not subject to the redistribution provisions of the GPL, and the company should, prior to any distribution, work with its lawyers to determine a strategy for out-licensing the software in a manner that is consistent with that position. The out-licensing strategy will depend on how the open source is actually being used. For example, where open source and proprietary components are discrete, a licensor may require customers to obtain their own licenses to the open source software or, if that is not desirable or commercially feasible, ensure that its own license agreements make it clear that open source software is licensed to the customer pursuant to the terms of a separate open source license and provide direct access to that license.

Prepare for Acquisition or other Liquidity Event. The foregoing strategies are essential to a company not only for maintaining its licensing strategy, but also in preparation for a sale, merger or financing. Sophisticated purchasers and investors now include open source as one of their due diligence items. Targets can expect to receive inquiries concerning the use of open source in connection with internal operating systems, and with any software or products licensed or sold to customers. Purchasers and investors often want to see detailed inventories of open source products used in the business, including copies of license agreements, and specific disclosures and representations concerning the use, modification and distribution of any open source software. Most open source license agreements also contain restrictions on the transfer or assignment of the license agreement. If the software license cannot be assigned to the potential acquirer, it may have to obtain those licenses on its own behalf, which will result in increased transaction costs. The response to these inquiries can have a direct impact on the valuation of the software and intellectual property assets of a company, as well as the perceived risk associated with the deal. For example, the failure to adequately respond to these inquiries can increase the likelihood that a purchaser will require onerous indemnification or holdback provisions in connection with an acquisition. A coherent and responsive open source policy can create a more efficient due diligence exercise, and eliminate the element of surprise.

Open source and commercial software licensing models, each at opposite ends of the licensing spectrum, appear to be moving towards each other. Large technology suppliers are adopting limited open source programs for their products, and open source providers are moving toward more mainstream commercial terms in connection with open source, such as infringement indemnification and the provision of support services. It is still critical, however, that businesses have a clear understanding of what open licensing is, and what the underlying license agreements both require and imply, before utilizing open source in any internal systems, and particularly before modifying open source and distributing it to downstream users.