Open Source Compliance: Getting Started Guide

This article discusses Open Source compliance and the challenges faced when establishing a compliance program, provides an overview of best practices, and offers recommendations on how to deal with compliance inquiries.

Traditionally, platforms and software stacks were built using proprietary software and consisted of various software building blocks that came from different companies with negotiated licensing terms. The business environment was predictable and potential risks were mitigated through license and contract negotiations with the software vendors. In time, companies started to incorporate Open Source software in their platforms for the different advantages it offers (technical merit, time-to-market, access to source code, customization, etc).

With the introduction of Open Source software to what once were pure proprietary software stacks, the business environment diverged familiar territory and corporate comfort zones (Figure 1). The licenses of Open Source software licenses are not negotiated agreements. There are no contracts signed with the software providers (i.e., Open Source developers). Companies must now deal with dozens of different licenses, and hundreds or even thousands of licensors and contributors. As a result, the risks that used to be managed through license negotiations must now be managed now through compliance and engineering practices.

A new computing environment necessitating Open Source compliance due diligence

Enter Open Source Compliance
Open Source software initiatives provide companies with a vehicle to accelerate innovation through collaboration with a global community of Open Source developers. However, accompanying the benefits of teaming with the Open Source community are very important responsibilities. Companies must ensure compliance with applicable Open Source license obligations.

Open source compliance means that users of Open Source software must observe all the copyright notices and satisfy all the license obligations for the Open Source software they use. In addition, companies using Open Source software in commercial products, while complying to the terms of Open Source licenses, want to protect their intellectual property and that of third party suppliers from unintended disclosure.

Open Source compliance involves establishing a clean baseline for software stack or platform code and then maintaining that clean baseline as features and functionalities are added. Failure to comply with Open Source license obligations can result in:

Lessons Learned

There are three main lessons to learn from the Open Source compliance infringement cases that were made public to date.

Compliance Challenges

Companies face several challenges as they start creating the compliance infrastructure needed to manage their Open Source software consumption. The most common challenges include:

  1. Achieving the right balance between processes and meeting product shipment deadlines: Processes are important, however, they have to be light and efficient so that they're not regarded as an overhead to the development process and to avoid Engineering spending too much time than necessary on compliance activities.
  2. Thinking long-term, executing short-term: The priority of all companies is to ship the product(s) on time, at the same time as building and expanding their internal Open Source compliance infrastructure. Therefore, expect to build your compliance infrastructure as you go while doing it the right way and keeping in mind its scalability for future activities and products.
  3. Establishing a clean software baseline:  Establishing a clean software baseline is usually an intensive activity over a period of time. The results of the initial compliance activities include: A complete software inventory that identifies all Open Source software in the baseline,  a resolution of all issues related to mixing proprietary and Open Source code, and a plan on fulfilling the license obligations for all the Open Source software.


Building a Compliance Infrastructure

The following subsections examine the essential building blocks of an Open Source compliance infrastructure required to enable Open Source compliance efforts.

Open Source compliance building blocks

Open Source Review Board

The Open Source Review Board (OSRB) is comprised of representatives from Engineering,  Legal and Open Source experts. The OSRB reviews requests for use, modification and distribution of Open Source software and determines approval. In addition, the OSRB serves as steering committee to define and manage your company's Open Source strategy.

Open Source Compliance Policy

The compliance policy typically covers usage, auditing and post-compliance activities such as meeting license obligations and distribution of Open Source software. Typical items that are mandated in a compliance policy include approval of OSRB for each Open Source software included in a product, ensuring that license obligations are fulfilled prior to customer receipt, mandatory source code audits, mandatory Legal review and the process and mechanics of distribution.

Open Source Compliance Process

The Open Source compliance process is the work flow through which a request to use an Open Source component goes through before receiving approval. Typically, it includes scanning code, identifying and resolving any flagged issues, Legal review and final decision.  As an example of  a  compliance process, you can review an article from HP entitled “FOSS Management Issues” available from

Compliance Project Management Tool

Having a tool to manage your compliance project is a great plus. Some companies use their bug tracking tools that are already in place, other companies rely on professional project management tools. Whatever your preference is, you would want the tool to reflect the work flow of your compliance process, allowing you to move compliance tickets from one phase of the process to another, providing you with task and resources management, time tracking, email notifications, project statistic and reporting.

Open Source Inventory Management

It is critical to know for each product what Open Source software is included, version numbers, licensing information, compliance information, etc. Basically, you need to have a good inventory of all your Open Source assets, a central repository for Open Source software that has been approved for deployment. This inventory will come very handy for use by Engineering, Legal and OSRB.

Open Source Training

The goal of providing Open Source training to your employees is to ensure that they have a good  understanding of your company's Open Source policies, compliance practices, in addition to understanding some of the most common Open Source licenses. Some companies go one step further by mandating their engineers working with Open Source software to take the Open Source training and pass the evaluation.

Open Source Portals

Usually companies maintain two Open Source portals:

3rd Party Software Due Diligence

In is highly recommended that you also examine software supplied to you by third parties. If third party software includes Open Source software, you need to ensure that license obligations are satisfied since this is your responsibility as distributor of a product that includes Open Source software. You cannot just point at the supplier and tell the Open Source community that it is the responsibility of the supplier to meet their obligations.  Therefore, you must know what goes into all of the product’s software, including software provided by outside suppliers.

Who's Involved in Open Source Compliance?

Several departments are involved in ensuring Open Source compliance. This section presents a generic break down of the different departments and their roles in achieving Open Source compliance.

Teams involved in open source compliance


Engineering and Product Team

Open Source Review Board

The OSRB team drives and coordinates all Open Source activities. Below we focus only on the compliance related activities.

Documentation Team

Supply Chain


Establishing Compliance Best Practices

This section presents on compliance best practices that fall under six major categories. Each of the categories represents a step in a typical compliance process.

  1. Scanning the source code,
  2. Identifying and resolving issues,
  3. Performing architecture review,
  4. Performing linkage analysis,
  5. Performing legal review, and
  6. Making the final decision.

Sample Compliance Process

Scanning Code

The first step in the compliance process is usually scanning the source code, also sometimes called auditing the source code.  Below are some common practices in this area:

Source Code Scanning Tools

There are several commercial and Open Source tools that offer the capabilities of scanning source code for potential open source issues.

Identification and Resolution of Flagged Issues

After scanning the source code, the scanning tool generates a report that includes a “Build of Material”, an inventory of all the files in the source code package and their discovered licenses, in addition to flagging any possible licensing issues found while pinpointing the offending code. What happens next?

Architecture Review

The architecture review is an analysis of the interaction between the Open Source code and your proprietary code. Typically the architecture review is performed by examining an architectural diagram that identifies:

The result of the architecture review is an analysis of the licensing obligations that may extend from the Open Source components to the proprietary components.

Linkage Analysis

The purpose of the linkage analysis is to find potentially problematic code combinations at the dynamic link level, such as dynamically linking a GPL library to proprietary source code component. The common practices in this area include:

As for static linkages, usually companies have policies that govern the use of static linkages since it combines proprietary work with Open Source libraries into one binary. These linkages cases are discussed and resolved on a case-by-case basis.

Legal Review

The best practices of the legal review include:

Final Review

The final review is usually an OSRB face-to-face meeting during which Open Source software packages are approved or denied usage. A good practice is to record the minutes of the meeting and the summary of the discussions leading to the decisions of approval or denial. This information can become very useful when you receive compliance inquiries. For approved Open Source packages, the OSRB would then compile the list of obligations and pass it to appropriate departments for fulfillment.

Responding to Compliance Inquiries

This section presents guidelines to observe when dealing with compliance inquires. These guidelines aim to maintain a positive and collaborative attitude with the requester of compliance information while investigating the allegation and ensuring proper handling in case of license violation.

Responding to compliance inquiries

Do not ignore Open Source compliance inquiries

Several companies received negative publicity and/or got sued because they either ignored requests to provide Open Source compliance information, did not know how to handle compliance inquires, lacked or had a poor compliance program, or simply refused to cooperate thinking it is not enforceable. By now, we know that none of these approaches is fruitful and beneficial to any of the parties involved. Therefore, as a general rule, companies should not ignore Open Source compliance inquiries. Instead, they should acknowledge the receipt of the inquiry, inform the reported that they will be looking into it and provide a certain date on when to expect a follow up.

Understand the reporter and the inquiry

It is recommended to understand who is the reporter, their motivation and verify if their accusation is accurate or even current. Furthermore, not every reporter understands licenses fully and sometimes there may be mistakes in their submissions. Therefore, you need to make sure that you fully understand the inquiry and that you have all the necessary information to isolate the problem and investigate it internally. If that's not the case, you can ask the reporter to be specific and provide you with the details you are missing to start your investigation.

Work collaboratively with the reporter

It is recommended to keep an open a dialog with the reporter. As a company that maintains rigid compliance practices, highlighting your Open Source compliance program and practices shows good faith efforts toward compliance. It is also advisable to send updates of your internal investigation when they are available.

Investigate and report results to reporter

After concluding the internal investigation (within an acceptable time limit) through the review of the  compliance due diligence completed for the specific software component (or product) in question, you need to inform the reporter with the results.

If a violation was found:

If indeed there is a license violation as reported, it is your responsibility to resolve the issue with the reporter, while being collaborative and showing good will. You need to understand the obligations under the applicable license and show how you will meet the obligations and how soon.


This article provided an overview of Open Source compliance, the challenges faced when establishing a compliance program, industry practices and recommendations on how to deal with compliance inquiries. Open Source compliance is an essential part of the development process. It is recommended to start with a simple, lightweight compliance process and  practices, learn and adjust as you proceed. You can look at common practices for inspiration but it is most likely that you will make adjustments to fit your specific company's needs. If you use Open Source software in your product(s) and you don't have a solid Open Source compliance program, then you should consider this article as a call to action.

Smart companies have strong Open Source compliance programs.


© 2008 SYS-CON Media