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

Player will show here

License Risks of Open Source

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 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.  Some of these lawsuits have been settled out of court, but all of the ones that have gone to trial have been settled in favor of the open source plaintiffs. In every case that settled out of court, the defendants agreed to pay the plaintiffs an undisclosed sum and agreed to honor the terms of the license.

  • 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:

  • What are the real legal risks of using open source inside commercial software

  • 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 GPL license as unacceptable for use inside a proprietary code base (hint: it is viral and can contaminate your own intellectual property).

  • The specific conditions under which it is completely safe to use GPL 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

  • What to do if you already have GPL licensed open source in your code that should be avoided.

If you stick with this and read through this website, you will be much more confident in your ability to sidestep the legal dangers of open source, and you will have a clear strategy to answer your customer’s questions about what is inside your source code.

What are the the legal risks with using open source inside commercial software?

  • You will attract a lawsuit.  This is a real risk.  There have been a number of lawsuits brought by open source advocates like the Free Software Foundation.  Being a small software developer with no deep pockets has not helped, some of the legal targets have been small software developers (like Monsoon Multimedia).  Being a large corporation with extensive legal defense resources has not helped, some of the legal targets have been F500 corporations (like Verizon, CISCO, and Ebay/Skype).    All were charged with not honoring the license obligations that came with the open source software that they incorporated into their proprietary software.  (More info on lawsuits…). Some of the lawsuits were settled out of court, and all of the cases that have gone to settlement have gone in favor of the plaintiffs.  The courts have ruled that not honoring the license obligations that come with open source software are enforceable, that even though the open source software was free, the license obligations are a legal contract, and enforceable in court.

  • Your customers will demand an accurate and comprehensive accounting of the open source inside your commercial software and the associated license obligations that go with it.  It turns out that if you customers distribute your software to their customers, they are as liable for the license obligations as you are.  And, your customers, may have a lot deeper pockets, so they are a more attractive lawsuit target then you are.  Your customers know this, and many will demand to know their potential liabilities, in addition to asking you for indemnification.

  • One of the engineers on your team has downloaded open source into your software without telling you about the license obligations.  Since most commercial software development teams have geographically distributed engineering teams with periodic turnover, it is almost impossible to be sure about everything that is inside your source code.

  • The open source inside your software can affect the valuation of your intellectual property.  This risk is especially important if you are going to be selling your company, as the acquiring company will certainly require a complete accounting of all of the intellectual property in your software.
So how do you protect against these legal risks of open source?  


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.

This is really no different from tracking the license obligations that come from any royalty bearing software that you incorporate inside your own software.  

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, 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 pretty 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.


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 charges $12,000 per audit (plus travel costs if you need us to do the audit on your site for a site outside the San Francisco Bay Area).  This charge includes all necessary scanning software from Source Auditor so no expensive third party tools are required.  This charge is also the same even if your code base is many hundred thousand lines of code long (the code base for a single audit must be associated with a single product or product line).  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: korak@sourceauditor.com

Copyright, Source Auditor, 2008, All rights reserved.