News & Insights

Open Source Software Solutions (Part 2): Understanding Open Source Software License Trigger Points and Resulting Obligations

October 28, 2016

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

Hamilton Brook Smith Reynolds

In part one of this series, we introduced the licensing and intellectual property (IP) risks surrounding open source software (OSS) code and the need for software development companies to adopt policies and procedures to manage the use of OSS in a safe and effective manner.  We also discussed the importance of getting to know the OSS code being used in your software products.  Once you have identified the OSS code being incorporated into your software products and the associated licenses, you are ready to understand the subject OSS license’s trigger points and resulting obligations.  

Properly utilizing the vast and readily available resources of open source communities can be a profitable business strategy.  A well-managed and effective OSS utilization policy will allow developers to incorporate OSS code when and where appropriate in order to save time and money in developing code.  An essential part of an OSS utilization policy is to understand if an intended use of OSS code would trigger obligations in the associated license.  If it is determined that obligatory terms of the license would be triggered, then companies are able to evaluate whether the resulting obligations can be met while still conforming to the planned business strategy for the specific software product being developed.

As discussed in part one, there are many different types of open source software licenses and each one may have different trigger points and resulting obligations.  Determining whether the use of a piece of OSS code in proprietary software will trigger obligations under an associated open source software license involves examining both how the piece of OSS code is being used and the terms of the attached license.  Often this examination is not very straight forward because each situation and license is different. 

While reading through the open source software license, focus on how the license defines a “derivative work.”  Some versions of the General Public License (a popular reciprocal or “copyleft” license) borrowed the term “derivative work” from Copyright Law.  While some of the earlier versions of General Public License used the term ‘derivative  work’, the interpretation of a derivative work as defined in these licenses is much broader and well beyond the scope of the statutory definition of a 'derivative work’ under the U.S. Copyright Law.  In fact, under some of the earlier versions of the General Public License, a derivative work can be created if software is tightly coupled to open source code, or by merely dynamically linking to an open source software library.  

So when exactly does software that a company develops and integrates with a piece of OSS code become a derivative work and consequently be subject to the associated open source software license?  This is a challenging question, at least partly because of the lack of good guidance from case law.  Richard Fontana, Senior Commercial Counsel at Red Hat, Inc., points out that open source communities “have tried on their own to develop answers to this question just by sharing their views and debates over what practices they consider acceptable and not acceptable, and this is something that open source developers in projects will discuss quite openly,” but there is not an easy answer, at least until we have case law that effectively guides the determination.

A good place to start the analysis is determining how closely integrated the OSS component(s) are with the proprietary software.  The closer and more intertwined the OSS components and the proprietary software are, the more likely the resulting software package is a derivative work and subject to the OSS license.  Because this is both a technical and legal analysis, it is beneficial to involve software developers and engineers in the determination of whether the license is triggered.  This is an example of where having non-legal employees who are educated about open source software issues is advantageous.   

Upon concluding that an OSS license is triggered, it is necessary to assess the requirements to comply with the terms of the license.  Generally speaking, so called permissive-type OSS licenses have minimal requirements to utilize and distribute the resulting software (derivative work), and may only require attributing the integrated OSS code to the original authors.  The defining characteristic of “permissive” OSS licenses is that they do not require derivative works to be licensed under an equivalent OSS license, nor do they require the resulting code be made available.  These aspects of permissive OSS licenses often make meeting their obligations more palatable for proprietary software companies than reciprocal-type OSS licenses.

Reciprocal OSS licenses, also known as “copyleft” licenses, are more restrictive.  Most reciprocal OSS licenses allow for source code to be reproduced, modified, and distributed only if the resulting software carries an equivalent availability.  The requirement that a company distribute a resulting proprietary software package under an equivalent OSS license can be directly at odds with the company’s business strategy. 

The third common category of OSS licenses is the hybrid license, which is sometimes referred to as an alternative license.  Hybrid-type licenses are a blend of permissive and reciprocal licenses and can contain clauses from both types.  Hybrid licenses are a great example of why it is important to read each attaching OSS license, regardless of what general type or category the license may fall into.  Drafters of OSS licenses are not held to specific categories of license or any particular clauses.  They are allowed to pick and choose the language and terms that comprise each license.  The only way to determine the particular license trigger points and resulting obligations is to read and understand each license attached to the integrated OSS code (i.e., the OSS code utilized) in a software product. 

There are no shortcuts to understanding OSS license trigger points and resulting obligations.  Ideally, each situation involving open source software should receive a thorough legal and technical review.  Increasing the number of employees that are informed about open source issues in software increases the pool of people who can aid in that review. 

In part three of this series, we will discuss the importance of educating company employees about OSS issues and policy.