The goal is to put in place policies, systems and processes to ensure a reasonable standard of care over the use of open source software. Companies can also put in place governance solutions that allow them to inventory their open source usage, implement open source policies, automate approval processes, track and audit open source deployment and ensure compliance with open source licenses.
A critical component of open source governance is to understand what open source software your enterprise is using and where it is being used. Besides helping you ascertain legal risk, understanding "what and where" is critical when systems go down, security vulnerabilities are uncovered or legal actions occur.
Surprisingly, most enterprises do not have a handle on how much open source they use. While some open source technologies are widely used by companies of all sizes, other packages are downloaded by developers, bypassing standard procurement processes and controls. In addition, some tools are often deployed unknowingly because they are bundled inside other packages the developer wants.
In fact, open source programs can contain dozens of other open source components, making it difficult to assess what open source software is used and what licenses are involved. Creating a baseline for open source inventory is a key step in governance. This will help you identify actions needed to mitigate legal risks and plan for the use, support and updating of open source components.
The license conundrum
Although open source is freely downloadable, each open source project comes with an open source license that governs the conditions of use. In fact, there are over 50 OSI-approved open source licenses, thousands of variations on those licenses and a huge number of unapproved one-off open source licenses. Although much discussion of open source licensing revolves around the GPL licenses, other licenses are much more common in open source software used by enterprises.
Unlike with commercial software, you have to research which license applies to downloaded open source software. In many cases there may be multiple licenses because of bundled code, and often the licenses are not clearly enumerated. Rather, it requires due diligence to uncover all that apply. In addition, some licenses may have conflicting obligations, even if they serve components of a single application.
Once you know what open source tools you have, you need to define and implement policies that govern their use. These policies should define the parameters and rules under which your organization will select, use and manage open source, including requirements for certification or support of open source, what licenses are acceptable, the processes and criteria by which open source may be approved, and guidelines for interaction with the community. For example, a policy might define whitelists of pre-approved open source tools, blacklists of forbidden open source tools as well as conditions under which greylist open source packages may be used.
Managing license approvals can range from a simple e-mail process declaring what is being used to something more sophisticated. What's important is to have a history of what's being used, where it's being used and what's been approved. As these approval processes are implemented and automated, they will become part of the standard development practices.
One thing you want to end up with is a complete audit trail of open source tools. If there's no record of what software is installed, then hunting down this history becomes much more difficult and expensive when a legal or production issue arises.
First, enterprises need to track open source that goes through the designated processes -- including downloads from an approved repository of open source and the history of approved uses. However, even with appropriate policies and processes, some unapproved open source may slip through the cracks. So enterprises also need to back up these efforts with periodic checks and audits to ensure everyone is following the rules. An audit allows enterprises to compare open source usage with policy and approvals and look for red flags.
In addition, just like with proprietary software, you want to ensure you have support for open source, control the versions of open source that are used and manage the update process. Many enterprises say they have myriad versions of a single open source component, and they are often unsure which versions are running where. The end result can impact uptime, efficiency and risk.
The tracking and auditing process should enable enterprises to see multiple views of open source usage -- by project, license, user, life-cycle state and server. Multiple tracking mechanisms -- request form, system scan, manual entry, build tools, downloads -- are essential to enforcing policy and managing compliance.
Together, all of these elements provide invaluable, actionable information for enterprises to implement open source governance and minimize risk. By implementing processes and tools for tracking and auditing open source tools, enterprises can take advantage of the significant cost savings that open source can offer while reducing the risks.
Grandchamp is CEO of OpenLogic (www.openlogic.com).