In this moment of  remote workforces and 100% digital customer interactions, two things have become clear:

  1. Every business’s confidence in its software supply chain is more critical than ever before.
  2. It’s a great time to re-evaluate policies and processes to ensure they are scalable and easy to enforce.

With these two key truths in mind, risk mitigation is a third, less discussed factor potentially impeding successful digital fluency and continuity during this time of change. But risk isn’t just privacy concerns and data breaches anymore. Open source software licensing should also be on your radar. According to Gartner’s 2019 Software Composition Analysis Report, up to 90% of your company’s software is built by third parties. Adoption of open source, especially at such a high rate and particularly in the context of continuous integration and deployment, also introduces meaningful licensing obligations. With software accelerating even faster to the forefront of business strategy, it’s important for every company to have a licensing strategy to help mitigate the risks inherent in a software supply chain composed primarily of open source components and dependencies.

Should you care about open source at your company?

Is it time to re-evaluate your risk mitigation process?

In addition to the shift to increasingly distributed teams and remote work, there are two engineering trends that have accelerated the need to re-examine compliance processes.

The first is CI/CD (also known as continuous integration and continuous deployment). Long story short, CI/CD means engineers are distributing new code at an increasingly rapid pace and often at significant scale. Depending on your business model, this could mean they are pushing new code and potentially adding new third-party licenses with legal obligations multiple times a day.

A great question to ask is whether your current compliance processes can handle this evolution. What that means, in terms of evaluating your readiness:

  • Does your scanning solution monitor every commit in real-time to keep updated inventories?
  • Can your solution be easily integrated across all your engineering teams?
  • Can your open source compliance process block problematic open source projects from entering your codebase?
  • Does your process provide automation in approving open source components?
  • Does your process automatically update any notices or attribution reports you are required to generate to fulfill legal obligations?
  • Does your process automatically enforce your third party licensing policy?
  • Can you track all of this in one centralized tool?

The second engineering trend to explore is dependency trees and modern languages. The rise of open source adoption has increased the complexity of the open source ecosystem to the point where developers are not always aware of the open source they are including. This is because of dependency trees. When a developer chooses to include Dependency X, they don’t always realize that Dependency X means your software will also distribute Dependencies A, B, and C, increasing the oversight needed to ensure no copy-left licenses are included.

This means your compliance process also needs to handle collaboration and context in order to give explicit feedback around high-risk licenses.

Good questions to ask to see if your process makes this type of collaboration:

  • Can legal teams pinpoint where in the codebase a problematic license lives?
  • Can legal teams advise developers on which dependency trees are responsible for including high risk licenses?
  • Do scanning solutions integrate with developer feedback workflows (CI/CD feedback or tool tracking feedback)?
  • Can developers easily understand how the licensing policy affects their software projects and which licenses are high risk?

For more information on evolving legal-engineering collaboration, check out this blog with our friends at UiPath.