Most software companies today leverage open source software to accelerate product development, reduce total cost of ownership, increase software stability, and enhance software security posture. In fact, according to the Linux Foundation's most recent report, 72% of enterprise companies cite leveraging open source frequently. As open source software continues to be adopted at an increasing rate, compliance with open source licenses becomes a more pressing initiative.
Why Care About Open Source Compliance?
The biggest reason to care about open source compliance is seizing business opportunity, or rather not missing it. Yes, there is a risk in being sued for violating the terms of an open source license. There is legal precedent for a license to be treated as a patent, which has all types of implications around IP.
However, the bigger and more common risk is the loss of revenue or market opportunity. The most obvious events that trigger open source due diligence are during fundraising, acquisition, and IPO events. However, there are an increasing number of companies that require a due diligence report, and sometimes even the continuous availability of a report, before closing a transaction. This is especially prevalent amongst enterprise brands and can also be a frequent requirement for any software deployed on-prem. Similarly, some online marketplaces like Google Cloud Platform require due diligence reports before allowing you to deploy your product in their marketplace.
So, what’s the cost of missing out on high potential revenue opportunities? It depends on the approach you take.
“Fire Drill” Due Diligence
Unfortunately, the fire drill approach is one of the most common approaches to compliance. Opportunity comes knocking in the form of a sales opportunity or a potential partnership, maybe even an acquisition, and the key stakeholders ask for your Bill of Materials or Attribution Report. Suddenly your legal, product, compliance, and engineering teams (or some mix of the above) are thrown into an all-hands-on-deck emergency to land the deal.
This process generally involves the engineering team scrambling to track down all of the dependencies. It might even require a code freeze in order to have a static body of code to analyze. In a fire drill your most knowledgeable, connected engineers will be leading the charge. They will have the best context on what open source components have been brought in, or at least how to navigate the codebase.
Next, the dependencies and their licenses are compiled in a list that legal must pour through to ensure that there is no legal liability to using each of these components. Any issues require tracking down the engineers to get a better understanding of why the software was used so context can be applied when resolving the issue.
Finally, key reports must be generated based on the given criteria.
“Fire Drill” Pros:
- No effort expended if issues do not arise
“Fire Drill” Cons:
- Missing product deadlines
- Prolonging a sales cycle for a large client, or worse losing them
- Delayed launch into an ecosystem
- Lost engineering productivity
- Inaccurate reports
As a company matures it may have more regular audit processes in place. Annual or quarterly audits may occur. This allows you to bake the cost of developing a technical due diligence report into your engineering cycle. Maybe you start to regulate the consumption of open source software. This is usually inadvisable, as it can cause serious delays for engineering or engineering might forgo the process altogether.
Traditionally semi-regular audits are performed with legacy code scanning tools. These tools require involvement from Engineering or DevOps and are often difficult to integrate. Professional services for both implementation and issue management are key parts of the business model for these platforms. Generally, they are used for a one-time scan. The resulting information about the open source components and their licenses then needs to be audited by the legal team to identify any potential conflicts, as well as determine steps for resolution.
Semi-Regular Audit Pros:
- Planned audits
- Lower exposure to risk
Semi-Regular Audit Cons:
- Decreased developer productivity
- High expenses for third-party consultants
- High labor cost for legal teams
Continuous compliance is a relatively novel concept. By definition, it means your company maintains compliance with every code commit. In order to achieve continuous compliance, generally, an investment in third-party software is required. This software should integrate with your developer’s build system (Travis, Jenkins, Circle Ci) and/or repository (Bitbucket, Github, etc) so that as new code is committed, new open source dependencies can be evaluated. This allows you to streamline issue management, reducing the time legal teams (and developers) are required to invest.
Continuous Compliance Pros:
- No interruptions
- Always ready to provide due diligence
- Reduced legal costs
Continuous Compliance Cons:
- Generally requires 3rd Party Software
Why Continuous Compliance Puts You at an Advantage
Modern software development has moved from the waterfall (one step at a time) to agile methodology. Complementing the rise in the agile method is the trend of CI/CD (continuous integration and continuous delivery and/or continuous deployment). Together, this means that software engineers are moving faster and making traditional compliance methods a barrier to success.
Long story short - good software development means continuously committing code to your production codebase.
Continuous delivery means in order to out-innovate or even keep up with the market, engineers need to be continuously adding new open source dependencies to their project without major roadblocks.
Changes in software delivery practices mean it’s time for open source compliance processes to adapt and mirror the software development practices. By harnessing a continuous compliance process, companies can provide due diligence reports and decreased risk without impinging on developer or legal efficiency