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 (https://www.openchain.org) 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.
Copyright, Source Auditor, 2008, All rights reserved.
