Open Source Software Audits: Why,

When, and How to Conduct an Audit

Contents Background. . . . . . . . . . . . . . . . . 2
Why it’s Important to Know What Open Source
Software You Use . . . . . . . . . . . . . . 2
Why You Need to Care. . . . . . . . . . . . 2
What is an Audit? . . . . . . . . . . . . . . 3
When to Audit. . . . . . . . . . . . . . . . 3
Preparing for an Audit . . . . . . . . . . . . 3
Assembling the Team. . . . . . . . . . . . . 3
Scanning for Open Source. . . . . . . . . . 4
Analyzing Open Source License Compliance . . 4
What You Get From an Audit. . . . . . . . . . 5
After the Audit. . . . . . . . . . . . . . . . 5
Compliance Best Practices . . . . . . . . . . 5
Open Source Software Audits April 2011

N
o matter what industry your business is in, your
company is almost certainly using open source
software. The question is whether you know how
you’re using open source, what licenses are in play,
and whether you’re meeting all of your license requirements. If
you can’t answer all of these questions — and most businesses
can’t — you may want to perform an open source audit.
Why? An audit can answer the question of what open source
software (OSS) is present in your code and what licenses that
OSS falls under.

About OpenLogic’s Auditing Solutions

OpenLogic offers a variety of products and services that help
enterprises understand what open source they use and what to do
to comply with open source licenses:
• Application Audit service
• Application Certification service
• M&A Open Source Audit service
• Open Source Fulfillment Center service
• OSS Discovery binary scanner
• OSS Deep Discovery source code scanner
• OpenLogic Exchange (OLEX) License Compliance

www.openlogic.com Page 1
Open Source Software Audits April 2011
Background
Open source is a broad term used to encompass a wide variety
of licenses. Generally, open source licenses allow redistribution
and modification of the work and do not place restrictions on
fields of use. The Open Source Initiative (OSI) is a community
organization that reviews and approves licenses that meet the
Open Source Definition (OSD). Many of the most popular open
source licenses are OSI approved.
Some of the most widely used open source licenses are
described as “copyleft” licenses. The GNU General Public
License (GPL) is the most well known of this type of license. In
general, the purpose of a copyleft license is to require modified
and extended versions of the open source software to be free as
well. Copyleft licenses, also referred to as reciprocal or “viral,”
generally require you to make source code available and to
release any derivative work under the same license. Because
copyleft licenses can impact the licensing requirements of your
own intellectual property, it is important that you understand
where those licenses are being used in your software.
It is also important to keep in mind that not all open source
licenses are compatible with one another. Some licenses, like
BSD-type and MIT licenses impose very few requirements on
those distributing the software, making them compatible with
other open source or proprietary licenses.
To ensure that you’re compliant with any open source licenses,
now and in the future, you first need to know what software is in
use in your business.
Why it’s Important to Know What Open
Source Software You Use
There are a number of reasons you need to know what software
your company uses. These reasons can include the need to
obtain support or maintenance, comply with internal policies, or
provide an audit as a requirement by external parties – such as
in the case of mergers and acquisitions. You also need to know
what software you have in order to comply with their licenses.
When you use proprietary software, support and maintenance
(updates, security fixes, bug fixes) all come from the vendor.
You need to be aware of their policies, which will largely dictate
when you upgrade, what you should budget for support, and
how maintenance will be addressed. Open source projects, on
the other hand, are usually available “as is.” As open source
software has become more ubiquitous, outside vendors have
stepped up to provide support. However, in order to make a
decision on what support is needed you need to be aware of
what open source software is running in your business.
How could you be unaware of the software running in your
business? This comes down to whether your IT department
is in compliance with your company’s software acquisition
www.openlogic.com
policies. Because there’s a direct cost involved in acquiring
proprietary software, someone in IT needs to request budget for
the software, it needs to be approved by his or her manager, and
it must move through accounting just like any other purchase.
In short, you have a paper trail and policies in place that should
effectively help track what proprietary software is in use.
What about software that’s free to download and install? Open
source is popular with IT departments not only because it tends
to be flexible, reliable, and powerful software, but also because
the steps to acquire open source present fewer hurdles to
solving problems. Indeed, you may not be aware of all the open
source that developers in your company have downloaded. If
you have no open source policy, the likelihood of untracked
open source usage is even greater.
This is not to say that your company should make it more
difficult for IT to deploy open source software. Instead, an
audit is an opportunity to learn what’s running in your business
and to effect policies that ensure that it’s being done with full
consideration of the requirements.
License requirements are, of course, a consideration. Litigation
has become a real risk in the last few years, since the Software
Freedom Law Center, a non-profit organization, has filed suit
against some high profile companies for non-compliance with
the GPL license.
Finally, your company may need to provide evidence of its
open source software usage to comply with other companies’
policies. Your customers may want to know what software is in
use when receiving services. If you have contracts with local,
state, or federal government entities they may have regulations
that govern what software can be used. Depending on your
industry, you may even have regulatory requirements to know
what software you are using.
Why You Need to Care
Since many license requirements hinge on distribution, it’s easy
to assume that they don’t apply to your company – even if you’re
modifying software for internal use only.
But distribution may be broader than you think. Even if your
business is not selling software or support for open source
outright, you may be distributing software. The most obvious
example of this is companies that are selling devices that
embed open source software. But you also could be distributing
software when you supply a contractor, partner, or customer
with software. Providing open source software to anyone
outside your company could constitute distribution that could
trigger the terms of the GPL or other reciprocal licenses.
Distribution could also be triggered by selling a subsidiary or
part of your business. Selling part of your company may not be
an everyday occurrence, but with larger enterprises it is a part
of business that you need to plan for.
Page 2
Open Source Software Audits April 2011
What is an Audit?
When many people hear about audits, they think of the Business
Software Alliance (BSA) and its infamous auditing process for
proprietary software. However, an open source audit is nothing
like this. An open source audit is an entirely voluntary (but
recommended) process to find out what open source software
your company is using, and under what licenses.
This is sometimes referred to as a “package review.” Note that
“package” or “project” refers to a piece of software, usually
downloaded as a single compressed file and may include any
number of files or subdirectories. For example, this could mean
a software package as an installable unit in an RPM or Debian
package, or a particular project like Apache or JBoss.
When to Audit
If you’ve never performed an open source audit for your
business, there’s no time like the present to begin. But there are
specific events that may, in particular, trigger the need for one.
For instance, if your company is going to distribute any product
that utilizes open source an audit should not be considered
optional. Keep in mind that your business distribute a product
that is not software but contains software (possibly even
unbeknownst to you). For example, most consumer electronics
today contain software. You need to ensure that your company
complies with the licenses of any and all software that it ships.
This is particularly true if your business relies on any
components that come from third parties. Whether it’s software
libraries or embedded components with firmware, you should
ensure that you have a full accounting of the software being
used in the product and that the license obligations have been
fulfilled. A number of companies have suffered bad press (at a
minimum) or worse, faced legal action, because their products
incorporated open source software that was not distributed in
compliance with the license.
The reverse of this is also true — if you’re in the business of
supplying software to another company for inclusion in their
products, they’ll likely wish to know about any use of open
source in the products.
Another triggering event for an audit may be a merger or
acquisition. If your company intends to acquire another, you will
likely want to perform an open source audit as part of the due
diligence process; indeed, this is becoming increasingly common.
Otherwise, the acquiring company could pick up liabilities that it’s
unaware of. It also helps assess the IT practices of the business
and how they will mesh with the new company. Similarly, if your
company might be acquired in the future, it is prudent to have
an open source policy and an on-going audit process instead
of waiting until an acquisition offer. Finding undisclosed open
source during M&A due diligence has the potential to reduce the
purchase price or even cancel the transaction.
www.openlogic.com
Another possible trigger would be if your company is seeking
financing — whether by taking on debt or by issuing public
shares. If issuing public shares, your company may have a
responsibility to disclose its use of open source or any liabilities
that may arise from the use of open source. If engaging with a
lender, they may wish to know at a broad level what liabilities
your company has or if open source is a material part of the
business.
Preparing for an Audit
Conducting an open source audit requires preparation, just like
any other form of audit. Here, though, you won’t need to gather
receipts and expense reports, but rather the source code for the
software that’s in use.
Start by getting a list from your developers of all of the open
source software they have used. This list is likely to be
incomplete, but will help you as you proceed with the audit.
Next, you need to get the code for any software that you’re
building and distributing or are likely to distribute. Be sure to
include all code that will be distributed as part of the product
or with the product, whether modified or not. Remember that
you’re not only looking for software that may have problematic
licensing or where you might have compliance issues; you’ll also
want to get a full assessment of the software you depend on to
ensure there are no other business considerations.
You can exclude anything that is not shipped or distributed. This
means, for example, if you’re using a compiler such as GCC to
build your software, it’s not necessary to audit GCC or your build
system unless you’re also distributing that. Note that you may
need to provide build installation instructions or scripts in order
to comply with some licenses (like the GPL) if they’re required to
build the final package.
Assembling the Team
Next, you need to get your company’s team together to
participate in the audit. This is crucial, as you will want to have
the right people with the necessary expertise involved.
First, you’re going to need one or more members of the
engineering team who can answer the technical questions —
how components are linked, how the build environment works,
specific versions of software in use, etc.
You will also need legal expertise as part of that audit. If your
organization has an internal legal team, choose someone from
that team who is familiar with open source software licensing.
If your business doesn’t have a legal team, or your legal team is
not familiar with open source licensing, you may need to engage
outside counsel.
You’ll also want to have representation from someone in
management who understands the business issues and can
set the expectations for the results of the audit. Maybe the
Page 3
Open Source Software Audits April 2011
primary focus of the audit is license compliance. Maybe the
focus is on discovering exactly which technologies are in use
and how to ensure policy compliance. Maybe the focus involves
a mix of all of the above. An audit may uncover issues where
there is no clear black and white answer, so your management
representative should work with legal to assess the company’s
risk profile in order to make decisions about how to respond to
results of the audit.
Lastly, you may also wish to have someone involved who can
provide the open source community perspective. Open source
projects that your company is likely to use often have a strong
community of developers. Understanding the perspective
of these communities can be a factor in your compliance
efforts. How your company works with these projects — and
whether it’s contributing back — can be nearly as important
as whether you’re complying with the license. Even if a license
doesn’t require contributions, you may want to look at policies
regarding contribution and decide that you will officially have
developers submit upstream. Alternatively, you may find that
your developers are already contributing, which may have legal
or policy implications for your company as well.
Scanning for Open Source
Once you have your team put together, you can begin the audit.
As previously mentioned, you have the option to audit source
code yourself or to hire a vendor to do the audit for you as a
service. In either case, you or the vendor will likely want to make
use of automated scanning tools. One thing that many teams
want to know is how automated scanning tools work, since
these are somewhat different than self-reporting or doing an
audit “by hand” by just looking through source code or using
basic string search tools such as “grep”.
Most scanning tools use a number of methods to see if code
in your product matches known open source projects or
libraries. A scanner does this by comparing your code to a large
repository of “fingerprints” of hundreds of thousands of known
open source projects or libraries. No repository is going to have
everything, but the size of a tool’s “fingerprint repository” is one
factor in the completeness of the audit.
Another important factor is the techniques used to find the
open source code. For example, OpenLogic’s scanning tools
can identify open source that is used regardless of whether it
is an entire project, a single file or a snippet of source code.
The tools can even detect source that has been modified — for
example by removing file headers, deleting or changing code.
OpenLogic’s tools will search for things like the name of files in
the project, pathnames, license text, or names in source code.
In addition, the tools look for hash codes for files and whether
blocks of source code match known projects.
The flip side of trying to find all possible places where your
code contains open source code is ensuring that there are as
www.openlogic.com
few false positives as possible. Because open source projects
often reuse libraries and code from other open source projects,
automated scanning tools may not be able to perfectly identify
the original provenance of open source code. As a result, some
scanners can produce a large number of matches, many of
which are incorrect or redundant. Too many false positives
means a lot of wasted time in reviewing and understanding the
scan results. OpenLogic’s scanning tools help address these
issues by using a variety of “noise reduction” techniques that
help you zero in on the correct matches.
When doing a scan, you may also run into situations where
some code may not be licensed at all or may not have an
obvious license. The reverse is true as well: scanning may
turn up licenses that don’t seem to be assigned to code at all.
In other cases, you can find multiple licenses within an open
source project that are in conflict with one another — that
is, you cannot meet the requirements of both licenses. These
situations will require additional research and investigation to
determine the licensing for the code. In some cases you may
want to contact developers from the original project to clarify
the licensing, if necessary.
If you’re using a service or vendor to assist with the audit, you
will want to know about the tools and process that vendor
follows. You may have the option to do an audit at your business
location or to provide the code to the vendor to complete the
audit in their offices. In the case of an audit done at the vendor
location, you will want to understand the “chain of custody”
for handling the code while it’s being examined. If the audit
was triggered by an external event, such as an acquisition or
the need to provide results to an OEM partner, you’ll also want
to specify who you want to see the results of the audit. For
example, in the case of an acquisition, the acquiring company
may receive a copy of the audit as well. Lastly, if you are using
a service provider for the audit, you’ll want to understand what
warranty or indemnification is provided to back up the report
provided.
Analyzing Open Source License
Requirements
Once the scanning and discovery phases of the audit are
completed, it’s time to sort through the licenses and determine
what terms are triggered. This is where the legal team is going
to need to look over the licenses that have been identified
and discuss with engineers how the projects are used. When
analyzing a license, you can break the license down into a series
of “if-then” statements. For example, a license may include
something like the following: if you distribute this open source
software, then you must also distribute a copy of the license.
Your legal team and development experts can then determine if
you are using the open source software in a way that triggers a
particular requirement.
Page 4
Open Source Software Audits April 2011
Once you know that a license obligation applies to your
particular use of the software, then you must determine how
to fulfill the obligation. It’s important to understand the details
of how to comply. For example, you might know you need to
distribute the source code, but the license may require the
source code to be provided in a particular way. Making the
source code available, but failing to do so in the way dictated
by the license may still be considered non-compliance. In
some cases, the meaning of certain clauses may be open to
interpretation.
Although many open source licenses are fairly straightforward,
they also present their own set of challenges. Most open source
licenses were not written by attorneys and do not track typical
statutory or contract language. Some license requirements
trigger off of particular engineering scenarios, requiring both
a legal and developer perspective to ascertain the meaning.
Although lawsuits have been filed regarding compliance,
almost all have settled. Consequently, we have no judicial
opinions regarding the interpretation of the more vexing license
compliance issues.
There may also be a variety of opinions from the open source
ecosystem on particular interpretations or expectations about
what a license means. The Free Software Foundation (FSF),
for example, has offered a lot of guidance on GPL licenses —
but that’s no guarantee that a court will agree with the FSF’s
interpretation. However, understanding the viewpoints of a
particular community that holds copyrights on the open source
code is still an important consideration for license compliance.
At the end of an audit, you’re looking to have a full bill of
materials for open source software in use in your business and/
or products and a list of the licenses and obligations that apply
to those packages.
What You Get From an Audit
After the audit is completed, you’ll have information about all of
the packages that are in use, as well as the licenses that apply
to those packages. Many open source projects embed multiple
other packages that use different licenses. It’s not as simple as
an application framework using just GPL — it may have GPL,
LGPL, Apache 1.1, Apache 2.0, and other licenses. All of this
should be detailed in a comprehensive audit.
You’ll also have analyzed which obligations in the license(s) are
applicable based on your use case. As the last step you’ll need
to determine whether you are in compliance with each of the
license obligations and whether the use of open source is in
keeping with company policies.
If you’re working with an outside firm like OpenLogic, you
may receive a list of the license requirements with the audit
results and a list of possible license conflicts. If your company
publishes software, you may find that you’re combining two or
www.openlogic.com
more licenses in a way that isn’t compatible. Simply because
the licenses are open source does not mean that they are
compatible with one another. All of this information can then be
used to ensure compliance with your license requirements or
make the necessary adjustments to your code as needed.
After the Audit
The end of the audit may only be the beginning. The next step,
regardless of whether you find any problems, is to create a
compliance checklist. Things to think about include ensuring
that all required notices are provided in your code and/or
documentation; providing source code or having it available
when required; and ensuring that any end-user license
agreement for your product is compliant with the licenses in
question. Going forward, you can be proactive about cataloging
open source usage and auditing to enforce compliance and spot
minor discrepancies.
You may need to find an alternative to any code that presents
a problem, but first ask if the code is really necessary. Perhaps
there is an easy work around or an alternative available under
a different license. Another option, in some cases, is to contact
the authors of the code and attempt to reach an agreement for
an exception to the license. Some projects or companies may
be willing to provide an exception, and are certainly more likely
to do so if the violation is unintentional and reported willingly.
It should be obvious at this point that the audit process, as
well as taking the necessary steps for compliance, will need
a collaborative effort between your engineering and legal
departments. Where compliance issues arise, engage your
executive management team as well to assess other options and
your company’s risk profiles.
The best case scenario, of course, is that your company is in
compliance already. But not knowing is worse than finding
non-compliance and being able to take steps to remedy it.
Whether you choose to engage an outside firm or perform your
own audit, it’s important that every business take the time to do
a full audit of the software that it is working with and ensure
that it’s complying with its obligations — not just the proprietary
software, but its open source software as well.
Compliance Best Practices
As you begin to audit your software for open source, you will
quickly realize that your audits will go smoother if you put in
place some basic compliance processes.
1. Put in place an open source policy. The policy should tell
your developers how and where they can use open source and
define the process for approving its use.
2. Track all open source usage. Make sure you document all
open source use: which versions are in use, where they are
used, how they’re used, and under what license.
Page 5
Open Source Software Audits April 2011

3. Maintain open source code. Your company should keep exact

source of the original projects as they’re received, as well as a
source repository with your changes and any code that you’re
shipping. Keep exact source and object code (binaries) for all
final versions of software that you’re distributing. Keep track of
what code has been modified.
4. Track licenses for open source. For each open source
package used, track all applicable licenses. Keep in mind that
the license associated with a piece of open source code may
change over time.
5. Have an open source review board. Create a review board
or other form of approval process for using open source in the
business. This process should be lightweight, to avoid delaying
development, but thorough, to avoid legal liabilities.
6. Appoint compliance officer or team. This person or group
will track compliance to ensure that your company follows
the license requirements and corporate policy for use of open
source after the audit.
Companies embarking on an open source audit may find that
there’s a lot of unfamiliar territory, but this should not inhibit or
dissuade companies from using open source. It’s simply a good
idea to be aware of what the use of open source in a business
entails, and handling it responsibly. Just as you need to have
a process to comply with the terms of proprietary software
licenses, you also need to have a process to comply with open
source licenses. An effective audit process will help achieve
this.

OpenLogic is a leading provider of open source solutions that enable enterprises to safely acquire, support, and control open source software. The OpenLogic
Certified Library, which encompasses hundreds of the most popular open source software packages, is accessible via OpenLogic Exchange (OLEX), a free web
site where companies can find, research, and download certified, enterprise-ready open source packages on demand. OpenLogic also offers open source
governance solutions, scanning, indemnification coverage, updates, and enterprise-grade technical support backed by the OpenLogic Expert Community.
phone: 1-888-OPENLOGIC
online: www.openlogic.com

www.openlogic.com Page 6