Nearly every company writing software uses open source software (OSS) to some degree, but not every company does a good job of governing that usage.
Why is governing OSS hard?
For starters, it’s not always easy to know exactly which OSS packages you’re using. Developers download whatever they like from the Internet and use what works for them. Reporting their use of OSS isn’t usually top-of-mind when developers are trying to solve technical problems. Later, sometimes years later, somebody comes along and asks what they’re using. Developers have good memories, but they’re not perfect. They also move from one project to another, change jobs, swap components out for technical reasons well after the initial installation, and otherwise make it difficult to know exactly what’s in the code.
What if I already know which OSS I have?
Even if you know exactly which OSS packages you’re using at some point in time and you capture that knowledge in everybody’s favorite tracking tool, an Excel spreadsheet, things change over time and this record tends to get out-of-date to the point of being entirely useless, often within a matter of months.
In many cases, the current OSS status for a piece of software needs to be assembled from a collection of emails sent back and forth among development managers and developers. As you might imagine, this is even less reliable than our spreadsheet.
What if I put “safe” OSS code in a repository?
Some companies determine which OSS packages are okay and put them on a shared drive. Then they allow developers to download from the repository, sometimes by assigning and managing explicit permissions placed on the files and directories. This seems like a good idea, but quickly becomes infeasible when you consider that a single OSS package can be used for multiple purposes and that one usage is okay but another is not. For example, using a GPL-licensed utility internally may be acceptable to your company, but linking it to your own commercial code that you ship to customers may cause your corporate attorneys to lose sleep at night. It’s very difficult to manage this kind of scenario with a simple internal repository.
How should I manage OSS packages?
Companies with a lot of developers that use many OSS packages need a sophisticated solution that can track and manage each instance of OSS, while avoiding the potential management nightmare that comes with such fine-grained control. They need a tool that automates OSS policies so that decision makers, such as architects and attorneys, are brought into the process only when required and not every time a developer wants to use OSS. These policies should automatically allow certain OSS to be used if it meets guidelines (e.g., internal use only, not modified, liberal license). Policies may require developers to state the reason for an OSS package and provide other information useful for auditing and management purposes. Policies may also reject certain OSS (e.g., modifying, linking, and distributing GPL code with company IP; disallow the use of package XYZ under all circumstances).
The governance solution should also support scanning so companies can understand which OSS they’re actually using and compare this to which OSS developers have approval to use. When a discrepancy is found, companies have the ability to remediate the situation, either by removing OSS or by getting it approved.
What about licenses and compliance?
Once you are sure exactly which OSS packages you’re using, you can then determine which OSS licenses are involved, and therefore what terms and conditions you need to meet. In many cases, license terms depend on how you’re using an OSS package. For example, a license may specify certain conditions that need to be met only when you redistribute the associated code. It’s also possible for multiple licenses to have terms that conflict with each other when multiple OSS packages are used together.
A robust governance solution will make it easy to understand the terms and conditions you need to meet when using OSS packages, including variations based on usage. It will also point out license conflicts and the need for further legal review.
OSS governance seems difficult – is it?
With many developers, especially ones distributed across geographies, and many OSS packages that have their own licenses, OSS governance can be a challenge if you don’t have a tool purpose-built for the job. This is especially true if you want to scan your codebase for OSS to make sure you’re in compliance with OSS licenses, even if a developer copies and pastes a relatively small amount of OSS code into your company’s application.
It’s possible to write your own software to track and manage OSS usage at a high level, but consider if this is the best use of your company’s resources. Over time, this software will require maintenance and upgrades. You’ll need to track more, less, or different information on usage requests. Your company’s OSS approval workflow will change. OSS packages and licenses will come and go. Scanning for packages becomes more difficult if your company begins to write code in a new language or wants to detect small OSS code snippets.
What is my best option for OSS governance?
OpenLogic can help you create and operationalize an OSS policy that works for your company. With OSS provisioning, governance, scanning, and support, you’ll have everything you need to benefit from OSS while addressing the challenges of managing such a diverse set of needs.