Over the last 10 years, open source has drastically transformed the way enterprises acquire and deploy software to support their operations. As general counsel for an open source and commercially licensed software company, I have been asked by hundreds of customers to review their use of open source software (OSS) and compliance with licensing terms. And as a former developer myself, I’ve gained unique insight into the implications of open source use by enterprises, both for internal applications and as embedded software in the products they license and sell.

OSS is ubiquitous and offers many advantages for commercial software development, including speed of development at little or no cost — but introducing third party software also introduces risks.

Open Source and the Strings Attached
The right to use another’s software is governed by a legal license agreement. In the case of OSS, the author distributes their software under one of a number of licenses considered to be open source, each with it’s own set of terms and conditions. These licenses fit into two major categories: Permissive and Copyleft. With Permissive licenses, there are few terms and conditions. With Copyleft licenses, the terms and conditions tend to be more stringent and bind any derivative work to the same terms and conditions.

Protecting Commercial Works, Protecting Your Fees
Most dangerous is the inclusion of Copyleft OSS in a closed source product. Under the GNU General Public License (GPL), the most frequently used Copyleft license, anyone who distributes that code or a derivative work must make the source code for the entire derivative work available under the same terms as the GPL license. Most commercial applications are developed on the premise that the source is closed and paid for. Requiring the release of source for free redistribution can be financially devastating for a commercial product.

Even Permissive open source licenses have requirements, such as retaining the copyright notices and providing prominent notice if the source has been changed (Apache). Failure to comply does not force the disclosure of source, but it could give rise to a claim of copyright infringement where the terms of the license are not followed.

Hidden Risks
There are often hidden risks associated with OSS packages. GPL code buried deep in software could give rise to a demand that you release your source code. When using larger packages, be sure to check not only the license for that package, but for all the included software.

If you use OSS from a project that is developed by a large pool of contributors, there may be little control over the source contributions. The larger the codebase, the larger the potential for problems. Risks include (1) contributors without a signed Contributor License Agreement (CLA), (2) contributors without permission from their employer to make a contribution; and (3) contributors who introduce code they’ve taken from elsewhere.

Quality Risks
Be sure to check the quality of an OSS package. Many projects may be good starting points, but are not “ready for prime time” for enterprise applications. OSS may be created by a developer or group of developers as a side project, without the same level of rigor and attention to quality as a commercial application.

Maintenance Risks
There’s also the issue of support and long-term maintainability. Organizations that use OSS in commercial offerings may not have a safety net of support if their application breaks as a result of third party code. They may have to turn to the community for support, versus paid, professional support from the vendor.

With open source projects, version-to-version breakage can also be an issue. Maintenance challenges are compounded when organizations build commercial offerings in part by assembling multiple open source components. The product becomes unstable as the developers struggle to keep the disparate components working together in the face of browser, operating system, and platform updates.