The Ins and Outs of Open Source Audits: Part One
No matter what industry your business is in, you're 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 as a starting point. 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.
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 play well 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.
This may not sound like it applies to your company, if you're not in the business of selling packaged software or support for open source. It may not, but know that the requirements can be triggered by other events that you need to be aware of.
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.
What is an Audit?
So what is an open source audit? When many people hear about audits, they think of the Business Software Alliance (BSA) and its infamous auditing process for proprietary software. Thankfully, 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 are you 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.
Why You Should Care What Open Source Software You Have?
There are a number of reasons you need to know what software you have. These reasons can include the need to obtain support or maintenance, to comply with internal policies, or to provide an audit as a requirement by external parties – such as in the case of mergers and acquisitions. Of course you also need to know what software you have in order to comply with their licenses.
Let's discuss support and maintenance first. 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 OSS has become more ubiquitous, outside vendors have stepped up to provide support. However, it's difficult to plan for this if you're unaware what open source software is running in your business.
But how could you be unaware of the software running in your business? This comes down to whether your IT department is in compliance with software acquisition policies in your business. 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.
But what about software that is 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 acquiring open source software present fewer hurdles to solving problems. Developers in your company may have downloaded multiple open source software packages without your being aware of it. If you have no open source policy, the likelihood of untracked open source usage is even greater.
This is not
to say that you should make it more difficult for IT to deploy open source software. Instead, an audit is an opportunity to learn what is running in your business and to effect policies that ensure that it's being done with full consideration of the requirements and to document what's in use.
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 free software organization, has filed suit against some high profile companies for non-compliance with the GPL.
Since many license requirements hinge on distribution, it's easy to assume that they don't apply to you — 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 (or conveying) software when you supply a contractor with software. Companies take a great deal of care to ensure that contractors are not seen as employees — therefore not part of the company. This means that distribution of open source software to contractors could constitute distribution that could trigger the terms of the GPL or other reciprocal licenses.
Other examples include sharing software with partners, or selling a subsidiary or part of your business to another company. Selling part of your company may not be an everyday occurrence, but with larger enterprises it's a part of business that you need to plan for.
Finally, you may need to provide evidence of your use of open source software to comply with the policies of other companies. Your customers may want to know what software is in use when providing services to them. If you have contracts with local, state, or federal government entities they may have regulations that govern what software can be used.
When to Audit
If you've never performed an open source audit for your business, there's no time like the present. But there are specific events that may trigger the need for an audit.
The first and most obvious is if your company is going to be distributing any product that utilizes open source, an audit should not be considered optional. Keep in mind that you may be distributing a product that is not software, but contains software (possibly even unbeknownst to you). For example, most consumer electronics products today contain software. You need to ensure that you're complying with the licenses of any and all software that you'll be shipping. This is particularly true if you're relying 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 may be a form of a merger or acquisition. If your company is acquiring 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 be picking up liabilities that it is unaware of. It also helps assess the IT practices of the business, and how they will mesh with the new company. On the other hand, 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 often opens the door to reduce the purchase price or cancel the transaction.
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.
How to Audit
Companies can use a variety of methods to audit their use of open source software.
The most basic option is self-reporting. That is, ask the IT department and/or developers in your company to identify what open source is being used. In essence, you're conducting an open source census inside your company. You'd also conduct a survey of third parties that provide software to your company to identify what software is in use. However, there are some drawbacks to this method. First, developers or providers often forget about (which) open source software they've downloaded. Second, developers are under deadline and may bypass policies to get the job done. Finally, open source projects often bundle other open source code or projects that have different licenses together; whoever got the code might not be aware of this. Although a self-reporting audit is a critical first step, you should assume it is incomplete.
Another option is to perform a manual audit, where software is inspected "by hand" to determine what open source software is in use. This means combing through files to determine what license the software is under and producing a report. This involves a great deal of time and effort and is also likely to miss some open source usage. When you are talking about tens of thousands of files or more, this is simply not a realistic or practical option.
Automated tools, or scanners, are available from OpenLogic as well as other vendors. There are a number of open source scanning tools as well. Scanning tools perform an audit by looking at the code and comparing it to an open source code repository or database and identifying "matches." This produces much more accurate results more quickly. An effective scanning tool will employ a variety of techniques to determine matches. Know, however, that no scanning product is absolutely perfect; no repository will have every open source project and the reuse of open source projects means sometimes a scanner will find multiple matches for the code in question. While a scanner helps automate the process, someone will still need to review and vet the results.
Finally, you can turn to an audit service. Here you hire a company like OpenLogic that will use multiple advanced techniques that determine what open source software is present in your codebase. You will then receive a report with an explanation of the findings enumerating your license requirements and possible problems. In OpenLogic's experience 100% of our audits have found much more open source software than the developers reported; including GPL'ed code that the company wasn't even aware of.
What You Get from an Audit
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 that apply to those packages.
This includes 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 being GPL'ed, it may have GPL, LGPL, Apache 1.1, Apache 2.0, and other licenses. All of this should be detailed in a comprehensive audit.
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 you're publishing software, you may find that you're combining two or 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 — ensuring that all required notices are provided in your code and/or documentation; providing source code or having it available when required; 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 use of open source and use audits to enforce compliance and spot minor discrepancies rather than serving as a first encounter with open source in your business.
You may need to find an alternative to any code that presents a problem for you. Ask first if the code is needed. Perhaps there is an easy work around or an alternative 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 is truly impossible, 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.
This work is licensed under a Creative Commons Attribution 3.0 Unported License
This work is licensed under a Creative Commons Attribution 3.0 Unported License