When choosing software for a project, developers have a number of factors to consider. Prime on the list is if it can accomplish a particular function and help them get their project to production faster. Hopefully, they are also considering the security implications of any components they choose, looking at how widely used they are and how well they are being maintained. 

One factor that commonly gets overlooked is how those components are licensed. It could be easy to think, "They are freely available on GitHub and in package managers like PyPI and npm, so they must all be OK to use. Right?" Well, not all open-source licenses are created equal, and some can have unwanted consequences for your codebase and, potentially, for your entire organization.

Let's take a closer look at open-source licenses and how you can quickly check to see what licenses are in your projects.

Most software is open source

As of 2023, reports found that 96% of all software contains some open-source components. At the same time, open source constitutes between 70% and 90% of any given piece of modern software solutions. There might have been a time when in-house developers typed all of the software a company deployed, but those days are long past. Modern software development means connecting mostly off-the-shelf components for the desired effect, hopefully in a sustainable way.

But where did that software come from? Who owns it? Who has which rights to use the code? Just because you can download it, does that mean you can run it as you see fit? Can you modify it? Can you sell it? These are just a few of the questions software licensing sets out to answer.  

Let's take a quick look at where open-source licenses came from to help us understand our current licensing environment.

Copyleft and licensing

In the early days of software development, software ownership was heavily tied to who owned the machines that could run it. In general, these were the military, very large companies, and universities. By the early 1980s, desktop computers and software you could replicate and install became commonplace. It made sense for the industry to adopt proprietary licenses, as their customers normally also got support guarantees and an update path. All commercial software vendors offer them to this day.  

Academia and home computing enthusiasts wanted to have a way to share their work in a way that encouraged collaboration. Richard Stallman, working at MIT, popularized the term "Copyleft" and created an open-source license called the Gnu Public License, or GPL, which is where he defined The Four Essential Freedoms of Free Software. It offered the software maker copy protection while clarifying the rights of the user. One perceived downside to the GPL is that the terms state any derivative work must also become free software.

Soon after the GPL was introduced, institutions like MIT and Berkeley (BSD) introduced their own permissive licenses, allowing the licensed software to be included in commercial software. Free and open software foundations like Apache and Mozilla soon created their own respective licenses, requiring attribution or that in certain situations, you must inform users of their rights. MIT and Apache are still the most common open-source licenses in production. 

BSL

There emerged a middle ground, the Business Source License, BSL, situated between pure commercial and open-source license models. MariaDB originated the idea when they forked their project from MySQL after the Oracle acquisition of Sun. The BSL prohibits the licensed code from being used in specific, defined ways in production. At the same time, the source code is publicly available, and anyone is free to use it for non-production purposes.  Other similar licenses, like the SSPL, have also been released with varying levels of restrictions. 

Risks of Non-Compliance with Open Source Licenses

Not adhering to the terms of open-source licenses can lead to serious consequences. Accidentally modifying and incorporating GPL-licensed code into your proprietary software without releasing the source code means you could be sued by the copyright holders. Legal actions can result in fines and may force the company to comply retrospectively, meaning you must open-source your product. Famously, this happened to LinkSys in 2003, resulting in the open-source firmware for the extremely popular at the time WRT54G.

Licenses can also be changed with any new software release. Software operating under a permissive copyleft could change to a BSL license with little notice. New restrictions could mean if you are using the latest versions in production, you might be violating the license terms, opening yourself up for a lawsuit. 

Beyond legal risks, open-source software licenses can bring operational risks in some situations. If a piece of critical software is found to be non-compliant with its license, you might need to replace the offending components, which, in worst-case scenarios, might mean completely reengineering your app.  

Which licenses are allowed in your organization?

Establishing a licensing strategy is an important step for any organization. Setting and communicating a clear policy of what is allowed and which licenses should never be included will help your developers make better choices as they are building applications.

Larger organizations will likely already have a policy in place. Every organization is going to have different goals and levels of acceptable risk. If you don't already have any guidance in place, then this is a conversation that you should have with your legal team. During that discussion, everyone will need to understand what licenses you have already used, and that is where SCA can help.  

Knowing what you have through SCA and SBOMS

GitGuardian Software Composition Analysis, SCA, is the latest addition to GitGuardian's code security platform. SCA can scan source code, identify dependencies and transitive dependencies, and report on any vulnerabilities from known CVEs affecting these dependencies. GitGuardian SCA also produces clean and up-to-date Software Bill of Materials, SBOMs. An SBOM will surface all the components in a piece of software, including the license being used. The platform produces CycloneDX-compliant SBOMs in JSON format, which can easily be shared and searched.

A dashboard view of your licenses

GitGuardian SCA goes beyond just producing these machine-readable documents and shows every component in our easy-to-use dashboard. GitGuardian not only shows the top-level components but also deeply nested transitive dependencies, which are the dependencies of your dependencies. From a single view, you can quickly see all the licenses in use across your repositories. 

You can filter by license type or specific licenses present. For example, if your company adopts a policy to replace all GPLed components, this view will quickly surface all the components with that license and link to where it is present, what we call the "source" of the component in your environment. 

Understand your licenses, and you'll understand your software

There are a lot of licenses out there, each with its own benefits and restrictions. Every organization needs to discuss which mix of licenses is going to be best for them, from a legal perspective and a code-sharing perspective. We hope that GitGuardian SCA can help your team facilitate this conversation by easily surfacing which licenses you have in-house and if any updates have introduced new ones.

If you are ready to understand your supply chain security and licensing better, we invite you to book a demo with us to start your free 2-week trial of GitGuardian SCA. 

*** This is a Security Bloggers Network syndicated blog from GitGuardian Blog - Code Security for the DevOps generation authored by Dwayne McDaniel. Read the original post at: https://blog.gitguardian.com/why-understanding-your-open-source-licenses-matters/