skip to main content

Open Source Software Solutions (Part 1): Getting to Know the Open Source Software in Your Products

October 4, 2016

By: Mary Lou Wakimura and Giovanna H. Fessenden-Fairbank

Hamilton Brook Smith Reynolds

As software companies turn towards open source software (OSS) solutions to develop robust and cutting-edge products, the enticement of highly-effective technology can obscure licensing and intellectual property (IP) risks.  In order to successfully navigate through licensing and IP infringement pitfalls, it is critical for software companies to adopt policies and procedures to manage the use of open source software in a safe and effective manner.  Several tips for such policies and procedures come to mind, and we will explore them through a series of articles.  The first tip is to get to know the open source software in your products. 

Under copyright law, the owner of a software copyright is afforded control over how, when, and by whom the software product is copied, modified, and distributed.  Authors of open source software exercise this control through an open source software license that defines the requisites surrounding the copying, modifying, and distributing of the OSS and its derivatives.  There are many different types of open source software licenses, but generally, they can be placed into three categories: permissive, reciprocal, and hybrid. 

Permissive licenses have minimal requirements to utilize and distribute the open source software.  For example, a permissive license may only require that attribution to the original authors of the OSS code be incorporated into a proprietary product.  On the other end of the spectrum, reciprocal licenses, also known as copyleft licenses, impose more restrictive obligations.  Most reciprocal licenses allow for OSS code to be reproduced, modified, and distributed only if the resulting software and source code carries an equivalent availability.  The third category of license is the hybrid license, which is a blend of permissive and reciprocal licenses and can contain restrictions and obligations from both types of licenses.  Regardless of the category of license, incorporating OSS code into a proprietary product without meeting the obligations of the attached license may lead to legal issues. 

Software development companies need to be concerned that their employees may be incorporating OSS code into proprietary software.  There is an abundance of OSS code available on the Internet, and developers may feel that they can incorporate the OSS into company projects.  It is important to keep in mind that triggering some open source software licenses will cause not only the component that utilized the OSS code, but the total resulting software package that a company is developing to be subject to terms of the license.   

These potential open source licensing issues are why it is critical for software development companies of all sizes to get to know the OSS code in their software products.  The first step is adopting an open source software policy that requires oversight and documentation of any utilization of OSS code. 

In addition to establishing a point person, it is crucial for companies to document all the OSS code that is going into a project, where the code came from, the business justification for using the code, and the code’s licensing agreement (i.e., specific terms).  We recommend that when software developers write their code, it’s important for the company to know where each line of code is coming from.  Given the viral nature of some open source code, companies should track the use of both open source and their proprietary code to help avoid contaminating proprietary software with the open source code obligations.  This information will become critical in evaluating whether an OSS license condition has been triggered, and if so, what obligations need to be met to comply with the license. 

Taking a proactive approach to overseeing and documenting the consumption of OSS code is vital to avoid discovering open source licensing issues after a product has already been released.  “It’s easier to put the water purification plant next to a reservoir, as opposed to at everyone’s homes, because it’s easier to catch the problems when they are all in one place as opposed to when they get spread out and disperse,” stated Matthew Jacobs, General Counsel for Black Duck Software of Burlington, MA.  Black Duck Software is a software company that provides a suite of software tools to help companies manage their open source use, and also conducts OSS audits.  OSS audits analyze a company’s developed software to discover hidden open source components along with the associated OSS license terms.  Commenting on Black Duck’s OSS audits, Mr. Jacobs said, “about 100% of the time, we find open source [code].  95% of the time [the company being audited] had no idea it was in there.  So these are big numbers and you start to wonder, how does this happen?  It happens because there is nobody there checking this stuff when it comes in the door – they’re waiting until it’s too late when the contaminated water has reached the household, if you will.”

Whether the OSS code is identified and documented as it is utilized or discovered through a software audit, getting to know the OSS code in your software products is crucial to avoiding or mitigating open source licensing issues.  Once the OSS code is identified, companies are then able to determine if any obligatory terms of the code’s attached license have been triggered and what requirements need to be met to comply with the triggered license terms. 

In part two of this series, we will explore the importance of reading and understanding OSS licenses and terms thereof. 
 

PDF File View as PDF