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.

Mitigate Your Legal Risk
You can mitigate your risks by following some key steps. Some best practices:

  • Track all third party software included in your distribution and the license type, and keep it up to date. Consider each addition carefully, examining the risks and the benefits.
  • Be sure to republish the license text of each work (and subwork), particularly if you are distributing object code only.
  • For Apache works, be sure to republish a copy of the Apache license, together with a prominent notice on any modified files that you have changed the files.
  • Consider the use of any GPL work in a closed source application very carefully. If your application can be considered and extension of the GPL work, you may be required to disclose your source. Seek counsel if your rights are in doubt.
  • Is the project supported by a specific group of developers and is there a thriving community dedicated to delivering a quality application? Or, is the software built by a single developer as a part-time project? Are contributions well vetted and under CLA?
  • Consider the effort and expense of replacing the software should you encounter any issues. Can it be swapped out easily, or is it intimately entangled with your application?
  • Consider the value of the contribution when compared to self-developed or commercial alternatives. Could you benefit from vendor engagement and professional support?

Conclusion
Open source software will continue to have a profound impact on how enterprises acquire and deploy software to support their operations. However, you should clearly understand the licensing implications and follow the rules. Consider quality, longevity, maintainability, community, contributors, and other risks before embracing or including a specific open source offering within your commercial product. By taking the several simple steps outlined in this article, you can reduce your risk and maximize returns.