Technology: A practical approach to open source software licensing

The use and licensing of open source software (OSS) continues to grow and it is not going away anytime soon. At a recent Open Source Conference in San Francisco, 62 percent of respondents to a survey indicated that OSS represented more than half their software deployment. Businesses have historically cited lower costs as the driving reason for relying on OSS, but easy access to source code and a community of talented developers, as well as freedom from vendor lock-in, also are major factors.

Regardless of the reasons behind this trend, it is important for in-house counsel to understand how to properly license OSS so that the software and licensing models selected provide their companies with the necessary use and distribution rights while also protecting the companies’ intellectual property assets.

OSS licensing risks

For software to qualify as OSS:

When distributed it must be free for users to redistribute

The software must be provided in the preferred form (i.e., in a form that is modifiable, including source code, documentation source and any necessary configuration files)

Users must have the option to modify the code and/or create derivative works

OSS source code can thus be viewed and changed by virtually anyone who has access to the software. While this can be beneficial to all parties involved, the terms of the applicable open source license can be onerous and should be both reviewed carefully and followed diligently to avoid IP infringement and breach of contract claims, and the subsequent forfeiture of rights to a company's proprietary software.

OSS license terms generally fall within the bounds of the open source definition established by the Open Source Initiative (OSI). As of the date of this publication, the OSI has approved more than 65 differentOSS model license agreements, and each model is unique. In general, most differ in how source code can be changed, embedded or incorporated with other source code, and the terms on which OSS is redistributed.

One significant risk associated with certain OSS licensing is often referred to as "copyleft." Copyleft occurs when OSS licensed under one of the general public license (GPL) models is incorporated into a company's proprietary software and the combined software is redistributed. If a company combines proprietary code withOSSsource code licensed under the GPL, and wishes to redistribute the combined source code (e.g., license it to customers), the combined code is automatically subject to the GPL terms. In other words, a company will no longer be able to assert copyright protection over its proprietary components in the combined code. In this way, the company has essentially copylefted the combined code.

Negotiation issues

When negotiating a technology services agreement involving the license and use of OSS, contract terms addressing IP rights, warranties and indemnities should be kept top of mind. For example, the terms of such agreements must clearly reflect the extent to which a company, anOSSlicensor and third-party providers have any rights to the software licensed under an open source license or developed and redistributed using suchOSS. Such agreements also should identify the party owning the IP rights to the originally developed software and derivative works of company or third-party materials.

All such agreements should also include a representation and warranty as to whether any software provided to the company does, or does not, contain OSS. IfOSSis included, the provider should include a history of where theOSScame from and how, by whom and when it was modified. Finally, the agreement should describe any interrelationships between open source, supplier, third-party and client software so that a company and its counsel can evaluate any potential risks of "copyleft" in the event that the OSS components are provided for reuse under certain OSS licensing models.

License and technology service agreements can also expose companies to IP infringement claims, and should therefore include indemnification terms protecting the company from third-party claims for such infringement. Unfortunately, if a company asks a service provider to take over IT functions that includeOSSsoftware, or to create a combination of proprietary software andOSS, the provider may try to exclude such software from its own infringement indemnity and may actually ask the company to indemnity it from such claims.

Minimizing future risk

To minimize future risk, it is important for in-house counsel to develop a sound open source policy that describes the OSS currently used or potentially licensed by the company. In non-legalese terms, the policy should establish procedures for obtaining approval and documentation before downloading, modifying and distributing OSS either on a standalone basis or as a component of other software, and should describe where the company's employees can locate more information.

Unfortunately, there is no one-size-fits-all solution, and each company must evaluate its own unique benefits and risks stemming from OSS. However, there are certain across-the-board practices in-house counsel can follow when developing their company’s open source policy. These include:

Performing an IP and/or IT audit to determine the company's, supplier's and third party’s rights with respect to OSS

Tailoring the policy to the company’s business model

Setting the company’s OSS policy and determining under which license models OSS is permitted to be downloaded and/or modified

Establishing an OSS committee or, at the very least, designating an official to review any requests for OSS

Educating and training employees and IT professionals about the policy

OSS is here to stay

As OSS becomes more mainstream, it is extremely important for in-house counsel to familiarize themselves with OSS licensing models, usage and redistribution restrictions, and to implement an open source policy to mitigate or avoid the risks associated with this growing technology trend.