Open Source Software
Authored by David Goldberg, Vice President and Associate General Counsel, GXS, Inc.
The internet has made so-called free and open source software (often referred to as FOSS) widely available to developers and technology users. The term “FOSS” refers generally to software that is intended to be free of restrictions on individual users and available to the public in source code (i.e., human readable code) form, typically under terms that permit modification and redistribution of such software. While there are a number of benefits to using FOSS, companies need to be aware of the potential risks arising from use of FOSS in a commercial environment and particularly from incorporating open source code in products or services that are redistributed or made available commercially. It is critical for in-house counsel to understand the principles behind free and open source licenses and the requirements, including license terms, that apply to these products. Many of the considerations that apply to open source software are similar in nature to those that apply to commercial software.
In-house counsel should work with the technology organizations in their company—especially software developers—to update software-related policies and procedures to appropriately govern corporate internal use and external redistribution of FOSS.
Using FOSS can save software developers significant time over writing code from scratch and many FOSS programs are quite well-established in the technology industry. However, because FOSS can be easily downloaded free of charge and without clicking through license terms, software developers may not realize that FOSS is still intellectual property that is subject to the specific license terms under which the software is provided. The terms of these licenses vary widely from permissive terms that effectively offer the software with minimal restrictions such as the required inclusion with any program incorporating the FOSS of a copyright notice and disclaimer, to licenses with “copyleft” provisions that govern downstream redistribution, if any, of FOSS or software derived from FOSS by licensees. Such copyleft terms require a licensee that redistributes FOSS to, among other things, make the object and source code available free of charge. Failure to review these license terms carefully and abide by them can result in liability for breach of contract or intellectual property infringement claims and, in the case of copyleft FOSS licenses, could result in a loss of control of proprietary software incorporating or based on FOSS. It is therefore essential that companies who use FOSS internally or as part of their commercial software products track these license requirements to ensure compliance in all uses of open source code.
The more restrictive form of FOSS licenses include terms—commonly referred to as “copyleft” clauses—which require any software incorporating or based on the FOSS code to be made available under the same license provisions (i.e., open source) as the original FOSS code used. The most common license of this type is the GNU General Public License developed by the Free Software Foundation (which also establishes a definition of “Free Software”). One of the risks associated with the ease of modifying and redistributing FOSS is that a company may inadvertently incorporate FOSS subject to a copyleft clause in its commercial software or other proprietary code that it licenses to third parties. In a worst case scenario, the company may be required to release as FOSS its proprietary code, or a portion of it, in source code format licensed for free under a copyleft FOSS license. Worse yet, if your organization develops software for customers who require that the customer own all rights in the developed software, use of FOSS in the developed work may put your company in violation of the “work made for hire” or similar ownership requirement of your customer agreement.
Use of FOSS may present other types of risk as well. FOSS licenses typically disclaim the kinds of representations and warranties of quality or performance that commercial software vendors usually provide. While major open source software projects, such as the Linux initiative or Apache, have one or more stewards as well as many individual developers who actively monitor code quality and track bugs, and design around or challenge any intellectual property infringement claims, support and quality controls for FOSS software distributed by smaller developers or initiatives may be less reliable.
Therefore, in addition to a review of the license terms under which such code is licensed, careful due diligence should be performed on open source software. In addition, some professional FOSS redistributors may offer corporate end users supplemental warranties or assurances regarding the quality or non-infringing state of FOSS or its implementation, depending on particular circumstances, and FOSS insurance is becoming available as well. (FOSS users may also take some comfort, however, in the fact that many large technology companies, collectively spend significant amounts each year to support the development and integration of open source software in connection with their software and services.) Further, open source projects create opportunities for contributors to introduce other improperly licensed or infringing code into the FOSS code for which your company would bear the risk (although the risk of harm from this is lower to end users than to companies that redistribute software).
Of course, as with commercial software, any free programs downloaded from the web have a risk of introducing spyware and vulnerabilities to viruses or other malicious code. Finally, while FOSS comes with the ability of the licensee to access the source code in the event of a bug or program error, smaller FOSS applications frequently lack support (although third party support may be available either through their third parties or through an expert community online).
Before using or incorporating code from an open source project or free software product into your own software product or service, it is critical that in-house counsel establish a company policy for use of FOSS with the buy-in of all software development, engineering and IT managers in your organization. First and foremost, the types of FOSS licenses need to be reviewed and approved in the context of the different types of uses. Commercial redistribution of modified FOSS will require a careful analysis of each applicable FOSS license, while corporate end users who only use FOSS internally may decide to rely on an approved list of license types, although some caution is required because of variation and modification of license forms. License requirements for FOSS differ depending on the particular use and, in particular, whether the FOSS is intended to be used internally or redistributed.
Once a policy is in place, your organization should maintain records regarding the open source code and freeware being used. These records will be important in the event there is a third party infringement claim or a quality issue that requires tracking down particular FOSS. As with license analysis, record keeping will become more critical in the event your company redistributes FOSS alone or with your commercial applications or incorporates FOSS into any commercial software or services. If your organization hires third party consultants to develop software, you may also consider adding a requirement to your contracts that prohibit the consultant using or including any FOSS in any deliverables to you without your consent, including FOSS which contains a “copyleft” provision that could result in the software your company paid for being released to others in source code form if you redistribute it to others. Where a policy is developed after FOSS was already used or, more importantly, redistributed, by your organization or where your company acquired software from a third party who may have used FOSS, it may be necessary to conduct an audit of prior practices or even conduct a review of the source code of existing programs to identify FOSS which may be incorporated.
Because the impact of not complying with FOSS license requirements can be significant, the same concerns for use of FOSS internally are equally important in the context of a business acquisition that includes software or technology assets. An acquiring company should make review of the target’s FOSS compliance policy and records a key requirement of the due diligence process and consider the inclusion of appropriate representations and warranties regarding FOSS, which may include requiring a schedule of all FOSS used by the target be included in the acquisition agreement or, at a minimum, assurances that the terms of all FOSS licenses have been complied with and that such FOSS licenses will not require or result in the disclosure of the source code of important technology. A target company should be prepared to comply with due diligence requests for lists of FOSS used in its business, including the license terms and description of FOSS uses—of course, having a strong compliance policy and record-keeping practices will make this task much easier!
Have an idea for a quickcounsel or interested in writing one?
Have an idea for a quickcounsel or interested in writing one?
Reprinted with permission from the Association of Corporate Counsel
2013 All Rights Reserved
Additional ACC Resources
Oct 2011 QuickCounsel
This QuickCounsel presents a concise framework for understanding, managing and controlling open source, and recommendations ...
Sep 2012 InfoPAK
This InfoPAK is intended to provide In-house counsel with a basic understanding of the fundamental issues surrounding open ...
Oct 2013 QuickCounsel
This QuickCounsel reviews some options for structuring multinational software licences and considers key issues that vendors ...
Oct 2012 Form & Policy
This sample checklist may be helpful in engaging with your companys business team during initial discussions of a proposed ...
On-Line CLE/CPD Program