Manage The License Obligations And Risks That Come With
Developing Commercial Software While Embedding Open Source Inside

Player will show here

Open Source Compliance Management

If you are a commercial software developer or manager, and you want to learn how to safely leverage open source to enhance your own source code, without incurring the legal risks that often accompany open source, you have come to the right place. 

  • Maybe you are concerned about a hit to your company's reputation if you are found to not be complying with the license terms specified by a community of volunteer developers, organizations, and companies.  Good open source software is provided by dedicated software developers who are providing their software under specific license terms. Independent of the legal requirements, complying with these terms is the right thing to do.

  • Maybe you have heard about the recent lawsuits where commercial software suppliers have been sued by open source advocates for downloading the open source while ignoring the license obligations.  

  • Maybe your customers have heard about some of these lawsuits, and know that sometimes the plaintiffs target them as customers instead of you as their software supplier, so they are demanding that you give them a thorough accounting of what is inside your software.

  • Maybe you suspect one of your engineers downloaded some open source and didn’t tell anyone about the license obligations.

  • Maybe you are worried that your source code includes some open source software that could impact the value of your intellectual property.

Regardless of the issue that brought you here, you have come to the right place.

Here you will learn:

  • How to form an open source policy which specifies which open source licenses are allowed inside your code base and which open source licenses should be avoided

  • The typical license obligations that come with the most common open source licenses

  • The specific reasons why most commercial software organizations would consider the copyleft license (such as GPL) as unacceptable for use inside a proprietary code base.

  • The specific conditions under which it is completely safe to use copyleft licensed open source

  • How to find out what open source is already in your source code

  • When it makes sense to use a professional audit firm to document what is in your source code

  • How to address if you already have copyleft licensed open source in your code under conditions that should be avoided.

Steps to Open Source Compliance - Create An Open Source Policy

The best way to protect yourself is to create a policy for the organization on using open source inside your software .  This policy should basically specify the approved list of open source licenses, ie, the list of open source licenses that have license obligations that the organization is willing to fulfill.  The policy should also specify a process and a review board, which can decide for the organization if a new license not on the approved list can be added to the approved list.  Finally, the policy should specify the non approved list, ie, the list of licenses which are definitely not acceptable to the organization because they contain license obligations that are too onerous for the organization to fulfill. 

While this may sound like some work, it is really the best way to protect the organization from the legal risks of open source.

As Laurie Wurster of the Gartner Group recently said: “Just because something is free, doesn’t mean it has no cost.”  “Companies must have a policy for procuring OSS, deciding which applications will be supported by OSS, and identifying the intellectual property risk or supportability risk associated with using OSS. Once a policy is in place, then there must be a governance process to enforce it.” 

So how do you get your arms around which licenses should be on the approved list and which licenses should be on the not approved list?

Well, there are over 70 licenses approved by the open source initiative and over 300 licenses tracked by the Software Product Data Exchange, so it is definitely not an easy task to understand all of the licenses out there.  Fortunately the 10 most popular licenses make up about 80% of the open source available, so understanding the first 10 licenses is a perfectly reasonable start.  You will need to create an open source review board consisting of both legal counsel and engineering management, who can learn the implications of the various licenses.  

A good resource is the Linux Foundation OpenChain project ( which recommends policies and processes, and provides training materials to get you started.  Source Auditor has contributed to the OpenChain curriculum and self certification website.  Through our consulting services, Source Auditor can help you apply the OpenChain recommended policies and process to your organization, which will help you to become OpenChain certified.

Audit Open Source

You should periodically conduct a complete audit of your source code, making sure you know exactly what open source is inside, and what the license obligations of that open source is.  You can either conduct your own internal audit, questioning your engineers and using standard tools like grep, or you can use a professional audit firm to make sure that your assessment is accurate and comprehensive.  You should also ascertain which of the embedded open source packages are deployed, ie, distributed with your product to your customers.  In addition, you should determine which of your own proprietary files are linked through static linking, dynamic linking, or include files to the open source packages that come with "copyleft" licenses.

The license obligations of most open source packages do not apply if you do not actually distribute either the object files or the source code files from the open source package.  This means that if you only use the open source package as part of your development or build process, the obligations do not apply.  They also do not apply, if you ask your customer to go get the open source package on their own, and you do not supply it.

Open Source License Obligations

Open source licenses can be classified first as either “copyleft” or “non-copyleft.”  Copyleft licenses are licenses which have viral provisions, that under certain conditions can infect your own proprietary source code, and force you to distribute your proprietary source code as open source (without royalties) under the same license.  The most popular copyleft licenses are the General Public 2.0 License and the Lesser General Public 2.1 License. 
Most commercial software developers consider the General Public 2.0 License as belonging to the unapproved list, ie, unacceptable to use within commercial software.  Unfortunately, more than 50% of the open source available is licensed through the GPL 2.0 license, since it is the license used by Linux. 
The Lesser General Public License is considered less onerous because the copyleft provisions only apply to your own proprietary intellectual property (files) if they are linked through static linking to the LGPL licensed packages, if they are not linked or if they are linked dynamically, the provisions do not apply.  It is relatively easy to remove this static linkage and to still use and distribute the LGPL open source package along with your own software.
If you find GPL 2.0 licensed open source inside your software you have a number of choices as to how to proceed, but you have to know it is there to do something about your legal risks:
  • Remove the open source licensed by GPL and replace it with your own proprietary software
  • Remove the open source licensed by GPL and replace it with a similar open source package with a less onerous license
  • Remove all linkages between your other software and the GPL licensed open source
  • Ask you customer to get their own copy of the GPL licensed open source
  • Accept the provisions of the GPL license and make your own files that are linked to it available under open source
The most popular non copyleft packages are Public Domain, BSD 1.0 and 2.0, Apache 1.1 and 2.0, variants of the CommonPublic License 1.0 (ie IBM Public License, Eclipse Public License, Netscape Public License, etc), and Java oriented licenses from SUN.  The requirements vary by license (here is a more thorough description), but they typically include attribution and redistribution requirements. 
For attribution, the requirements can include any or none of the following:
  • Keep copyrights in place in the source code or the documentation
  • Do not use the names of the open source copyright owners as an explicit or implicit endorsement of your software, ie,in advertising or other media.
  • Provide a prominent notice giving credit in the source code or the documentation
  • Clearly mark any modifications in the source code or the documentation
  • Provide a notice saying where the user can get the open source package source code and any modifications made by you
For redistribution, the requirements can include any or none of the following:
  • Make the original open source package source code available for free under the same license
  • Make any modifications to the orginal open source package source code available for free under the same license
  • Make any of your own files linked to the original open source package for free under the same license

The Public Domain licenses are the least restrictive with no obligations, while the Common Public License variants are the most  restrictive.  Many of these licenses have additional restrictions as well, for example, the Common Public License has a  provision that makes it difficult to use the open source package and then sue any of the open source copyright owners for patent infringement.  Some of the other licenses such as those from SUN and others, have restrictions on the ability to modify or distribute the source code, or to distribute even the object code without packaging it with your own software.

Most of the non-copyleft licenses are not onerous and can be added to the approved list in your open source policy.  What is important, though, is to fulfill the obligations, and for example, to set up a URL where the open source package and any modifications can be downloaded by users under the same license.

I hope at this point, you are becoming more confident about how to manage the legal risks of using open source inside your commercial software.  The key points are:
  • Create an open source review board which maintains the approved list of open source licenses

  • Understand what the key licenses mean to your organization’s obligations

  • Create an open source policy with an approved list of licenses and an unapproved list of licenses

  • Audit your source code and create an inventory of all open source present, including the associated license obligations

  • If any open source is present from an unapproved list, remove and/or replace it

  • Track all open source submissions on an ongoing basis, and do not allow any open source to be added which is not on the approved list of licenses

Open Source Audit

For situations where you need a complete and accurate audit of your source code, ie, doing it on your own is not accurate enough, we suggest you use a professional audit firm like Source Auditor.
Source Auditor has a great deal of expertise and experience in conducting open source code audits.  Our methodology, expertise, and proprietary software tools can insure a comprehensive and accurate audit, as well as sound recommendations on what to do given the audit results. 

Source Auditor has the tools and the expertise to to audit your source code at a very competitive price.  Our pricing includes all necessary scanning software from Source Auditor so no expensive third party tools are required.  We are also very proficient with other available third party tools such as BlackDuck Protex and can use those tools as desired.  We only bill after you approve the audit results, so, the results are 100% Satisfaction Guaranteed.

To see if an audit from Source Auditor makes sense for your company, email me here:

Copyright, Source Auditor, 2008, All rights reserved.