Free and Open Source Software : Managing Risk
By Mark Radcliffe, Partner, and DLA Piper
The use of free and open source software (FOSS) has become ubiquitous across all industries from financial services to retail. Technology research firm Gartner recently estimated that 95 percent of mainstream IT organizations will use open source software in mission critical systems in 2015. One commentator estimated that more than one million FOSS projects are available. Many FOSS products are used across wide variety industries such as the Linux operating system, which runs products from televisions to nuclear reactors. Even Microsoft Corporation, once the most ardent supporter of proprietary software, has joined the FOSS movement: among other actions, Microsoft open-sourced its .NET framework.
Yet, according to Gartner, less than 50 percent of companies have a policy for managing the use of FOSS. Such policies are essential if companies want to remain compliant with the obligations under FOSS license. The failure to comply with some of those terms in many FOSS licenses will result in the automatic termination of the rights to use the FOSS projects. Such automatic termination occurs when a company violates several of the terms of the General Public License, version 2 (GPLv2).
" The most effective way to manage the use of FOSS and avoid litigation against you and your customers is to have a FOSS Use Policy "
GPLv2 is the most widely used FOSS license, therefore compliance is increasingly important because of the increase in litigation to enforce FOSS licenses. In the past, community groups, such as the Software Freedom Law Center and Software Freedom Conservancy, have enforced FOSS licenses primarily through community pressure with a focus on compliance rather than litigation or damages. However, the traditional community enforcement groups are getting more aggressive.
The Software Freedom Conservancy, for example, is supporting litigation in Germany brought by a contributor to the Linux kernel, Christoph Hellwig, against VMware claiming that the integration of its ESXi product with the Linux kernel violates the terms of GPLv2. The lawsuit claims that the ESXi product is so tightly integrated with the Linux kernel that VMware’s propriety product is a “derivative work” of the Linux kernel
However, in the past two years, a new group of enforcers has appeared: commercial companies who, unlike community enforcers, are interested in traditional commercial remedies such as damages and court orders stopping distribution of products. A good example of this new trend involved Versata Software Inc. (a vendor of proprietary software), which became entangled in three lawsuits because Versata incorporated software from Ximpleware licensed under GPLv2 into Versata’s software. The Ximpleware software was “dual” licensed under the GPLv2 and a proprietary license. Versata used the GPLv2 version, but deleted all Ximpleware
notices as well as copies of the GPLv2 license. These actions violated the terms of the GPLv2.These failures were discovered by one of its customers when Versata tried to terminate the agreement with such customer. This defense by Ameriprise raised so many issues that the termination was delayed for more than two years. In addition, Ximpleware sued Versata for patent and copyright infringement and Ximpleware sued all of Versata’s licensees.
These disputes have led to customers demanding that companies provide contractual assurances that they are in compliance with the FOSS licenses. And potential acquirers also are focusing on these issues and many large companies now have a separate due diligence process focused entirely on FOSS license compliance.
The most effective way to manage the use of FOSS and avoid Versata’s problems is to have a FOSS Use Policy. Although the FOSS Use Policy will deal with legal compliance, it also should provide a framework for managing the use of FOSS, including a framework for selection and validation of FOSS projects.
The FOSS Use Policy should include infrastructure and should be flexible and lightweight so that the engineers do not try to avoid it. It needs to cover use by company employees as well as FOSS from third-party products integrated into your products and FOSS from acquisitions.
The critical components of a FOSS Use Policy as are as follows:
► A company should recognize it is using FOSS and manage that use.
► Companies should develop a process for reviewing proposed FOSS projects and validating that they have necessary security and functionality.The process should include a legal component to ensure that the FOSS license is consistent with the underlying business goal. For example, some companies ban the use of copyleft software (such as GPLv2) because of the uncertainty of the scope of its obligations. In addition to legal compliance, the policy should include input from engineering and business parts of the company. Many companies use the “green light-yellow light-red light” approach: some licenses are automatically permitted (green), some licenses are permitted for certain uses (yellow), and some licenses are not permitted except in rare circumstances (red).
► The process needs to be implemented and managed effectively. This implementation is most effective if the process becomes part of the development process rather than being a final check prior to release when there is enormous pressure to release the product. Many companies use a committee with representatives of the company’s legal, business and engineering functions to make these decisions.
► The FOSS Use Policy should also include a process for approving contributions by employees to FOSS projects. Many recent computer graduates already contribute to FOSS projects and want to join companies that are “FOSS friendly”. Such approvals are important because many FOSS licenses include patent licenses, which could affect the patents of your company. Consequently, the FOSS Use Policy should address these issues.
The use of FOSS use is ubiquitous, but needs to be managed, to the cost and risk of failing to manage FOSS use is increasing.