A New Era of Code Quality: Beyond bugs and into legal license compliance and risk management

In the interconnected world of software, few applications are conjured into existence entirely from scratch. Developers consistently draw upon a vast ecosystem of open-source libraries, frameworks, and external components, all designed to expedite coding and reuse established solutions. It’s simply efficient: Why should anyone invent a solution when a perfectly good one already exists?

However, while incredibly efficient, reliance on third-party components comes with its own baggage: Licensing. It may seem like a minor detail, but failure to understand or comply with the terms of even one license — among the dozens or hundreds typically found in a modern application — can lead to severe legal disputes, the forced open-sourcing of proprietary code, and substantial financial penalties. This makes license compliance a remarkably complex and unglamorous undertaking.

💡 This article is designed to accommodate different learning and reading styles, so feel free to jump ahead:

• License and litigation and why it’s important to pay attention

• The intersection of dependency management, SBOMs, and software licenses

• How license management contributes to code quality

• More resources and references

License and litigation and why it’s important to pay attention

Modern software projects often have a deep “dependency tree,” where a direct dependency itself relies on other libraries (transitive dependencies). It’s easy to overlook the licenses of these indirect dependencies, leading to hidden compliance risks. Unfortunately, “I didn’t know” is not an excuse that holds up in court.

Not even the biggest corporations are immune to the consequences of license mismanagement. License violations have cost companies millions of dollars, forced code disclosure or refactoring, injunctions, settlements, and precious time and resources that could have been spent otherwise.

The intersection of dependency management, SBOMs, and software licenses

What is an SBOM?

An SBOM acts as a comprehensive, machine-readable inventory of all components within a software package. Much like an ingredients list on a food product, a Software Bills of Materials (SBOM) details every piece of open-source and proprietary software, libraries, and modules that make up a given application, along with their versions and origins. And just as a food label might list “enriched flour” and then detail its components like niacin and thiamine, an SBOM also breaks down your dependencies’ dependencies, giving you a complete picture of every ingredient. For developers, maintaining an up-to-date SBOM is crucial for visibility into their software supply chain, enabling them to track and respond to security advisories more effectively.

An example of an SBOM in JSON according to the CycloneDX format.

What is dependency license management?

As developers, we are usually pretty aware of the importance of checking our “list of ingredients” (albeit often against our will while detangling dependency conflicts) and even if we don’t always immediately address CVEs, we at least know we should probably cut a card for the task. Another aspect of dependencies that we may know less about is license management.

At its core, a software license is a legal agreement that defines the terms under which you can use, modify, and distribute a piece of software. Think of it like a contract between the creator (licensor) and the user (licensee). Most open-source software comes with specific licenses that dictate how it can be used, modified, and distributed. Failing to comply with these licenses can lead to legal complications, intellectual property disputes, and financial penalties. An SBOM can serve as a foundational tool for license compliance, providing a clear record of the licenses associated with each component. This becomes particularly important in environments where certain license types (e.g., strong copyleft licenses like GPL) may have significant implications for the broader software product.

The intersection of SBOMs, CVEs, and licensing forms the backbone of effective dependency management. In an era where AI hallucinations and the accidental inclusion of malicious or problematic packages are growing concerns, the practice of diligent processes for generating and analyzing SBOMs become indispensable to the production and deployment of quality code.

What are the different kinds of software licenses?

These licenses are the legal frameworks that define how you can use, modify, and distribute software, whether you’re building a new application, contributing to an open-source project, or simply using a program on your computer. Understanding the distinctions between these licenses is crucial for avoiding legal pitfalls, ensuring compliance, and making informed decisions about your software projects. Licenses can be broken down into the following broad categories:

• Standard permissive: The most commonly used permissive licenses. They grant broad permissions to use and modify with very minimal obligations (primarily attribution) and have all the essential elements of permissive open source licenses. Examples include MIT and Apache software licenses.

• Non-standard permissive: Permissive licenses that lack one or more essential elements of modern permissive open source licenses, or impose complex or confusing requirements. Examples include Artistic 1.0 and the WTFPL software licenses.

• Weak copyleft: Weak copyleft licenses require sharing your changes and additions to the licensed software when you give copies to others. Examples include GNU LGPL and the Mozilla Public License.

• Strong copyleft: In addition to the requirements of the weak copyleft licenses, strong copyleft licenses require you to share larger programs that you build with the licensed software when you give copies to others. Examples include the GNU GPL license.

• Network copyleft: In addition to the requirements of strong copyleft licenses, network copyleft licenses require you to share larger programs that you build with the licensed software not just when you give copies to others, but also when you run the software for others to use over the Internet or another network. Examples include the GNU AGPL (Which is different from the GNU LGPL!) and the Server-Side-Public License.

• Maximal copyleft: Maximal copyleft licenses answer the question “When does the license require you to share?” differently than other licenses. Maximal copyleft licenses require you to share software you make with others, and to license that software alike when you do. Examples include the Parity and Reciprocal software licenses.

• Uncategorized: Nonstandard licenses that do not fit into the above categories.

With SonarQube Software Composition Analysis, each dependency includes information for all the dependencies it relies on so you can see exactly which licenses are being introduced into your project.

How license management contributes to code quality

At a fundamental level, high-quality code embodies these key traits: it’s reliable, secure, and maintainable. Software licensing may not be the first thing that comes to mind when considering code maintainability, but think of it this way: Much like tech debt, leaving license management for later can result in “legal debt” that almost inevitably comes to collect. Dependency trees are already thorny when it comes to keeping versions in line, just imagine having to remove dependencies due to license violations. Or worse — the possibility of being forced to recall a product (and all the effort that went into it). Decommissioned code is not maintainable code.

Moreover, because you can’t oversee the licensing decisions or compliance procedures governing your dependencies’ code, you need an alternative approach to ensure their potential license problems don’t jeopardize your own software’s legal standing. Nowadays, a rigorous and intelligent code quality discipline absolutely must encompass legal considerations like dependency license management.

SonarQube’s Software Composition Analysis (SCA) goes beyond just listing your project’s dependencies. It also provides a comprehensive overview of associated license risks, complete with holistic scoring and actionable remediation steps. This allows you to prioritize and address license compliance issues according to your organization’s specific needs.

💡 Want to learn more about SonarQube Software Composition Analysis? Check out a tutorial here.

More resources and references

• Read more about coding best practices here.

• Read more about best practices for dependency risk management in particular here.

• For a breakdown of other top security flaws and how to address them, check out Jonathan Vila’s article on the topic.

• Want to learn more about SBOMs? This article provides a comprehensive overview.