Open Source Compliance: A Cheatsheet for Students

Open source projects release software component for public usage, enabling developers to use ready-made software components. This is incredibly useful, because it means you don’t have to start your project from scratch. However, it doesn’t mean you can use the code as-is, claim ownership and resell it as your own. 

Each open source components are available under a specific license. Each open source license grants different usage rights. Non-compliance may result in reputational damages and monetary penalties. To help you understand open source license compliance, this article explains the main categories of open source licenses, and reviews ways to ensure compliance.

What are Open Source Licenses?

Open source licenses specify how open source, or publicly available, code can be used. These licenses may restrict how open source code can be included in a project, who can use code, and what limitations are placed on projects that use code. 

These licenses can cover all types of open source components, including code blocks, libraries, frameworks, applications, and platforms. Generally, when a project is made public, the project maintainers specify what licenses it falls under. 

Why Open Source Compliance Is Important

Open source compliance is important for both ethical and legal reasons. Ethically, open source is created by development communities to help further innovation and to provide wider access to beneficial technologies. Ignoring open source licensing dismisses the importance of these communities to advancement. It also abuses the work that was done as a volunteer effort by well-meaning developers. 

Additionally, abusing open source projects and ignoring license restrictions can have an impact on your professional status. If other developers know that you have stolen another’s work and claimed it as your own, they may be less likely to want to work with you or respect your own development work. 

Legally, open source compliance is just as valid as any other licensing. This means that you can be sued for using code against license. Cases can be filed by companies that offer code as part of a dual licensing strategy or by project maintainers. 

If these cases succeed and you’re found to be in breach of compliance you may have to pay damages for the abuse. You will also likely have to stop selling your software and may even be forced to make all of your source code open source. 

Main Categories of OSS Licenses

There are over 200 different types of open source licenses available but only a handful of these licenses are widely known or used. Because of the sheer number of options, it is not practical to try and remember them all. Instead, it’s important to understand the two main types of licenses that exist—permissive and copyleft. 

Permissive licenses

Permissive licenses allow you to use, modify, and share open source code with minimal restrictions. The main requirement that these licenses contain is that you attribute any code used to the original creators. It does not restrict you from including code in private projects or from creating proprietary products that include permissively licensed code. 

Common examples of this license type include Apache, MIT, and Mozilla Public License (MPL).

Copyleft licenses

Copyleft licenses are more restrictive than permissive licenses. Rather than allowing free use of code without barriers, these licenses require that when projects use or modify code, all source code must be shared. This means that you cannot include code with a copyleft license in a proprietary product. 

The most common example of this license type is the GNU General Public License (GPL). 

Ways to Execute OSS Compliance

To ensure that you are maintaining compliance with open source licensing there are two main methods you can use — manual and semi-automated. 


Manual compliance checking typically involves creating a spreadsheet or database of any open source components you are using. For each component, you verify the version you’re using, the license it falls under, and how you’re using the component. As long as your use matches license requirements, you’re compliant. 

While this method is a sure way to verify compliance, it is only practical for smaller projects or those with few components. Even for these cases, this method typically requires you to restrict the types of licenses that can be included to prevent verification from becoming overwhelming. If you don’t, licenses may conflict, negating your efforts. It also requires developers to be diligent about logging all components they include and notifying whoever is responsible for verifying compliance. 


Semi-automated compliance checking is becoming more common as the use of open source increases. This is particularly true for larger projects and those that include many open source components. This is because manually checking a large number of components requires significant resources while automating at least some of the process can save significant time. 

Although many organizations may try to fully automate this process it’s near impossible to do so currently. This is because many components do not explicitly define their license in a way that is easy to find or automatically ingest. For these components, manual checking is still needed. 

When semi-automated methods are used, there are a variety of tools that organizations can employ. Some of the most commonly used include:

  • File scanners—scan applications or application files to identify components. These tools are useful when you are unable to directly scan source code. 
  • Code scanners—scan your source code to identify components known to be open source. These tools help you catch inclusions that may otherwise be overlooked or that developers may have misidentified. 
  • Continuous integration (CI) scanners—code scanners that are incorporated into CI pipelines and build tools. These scanners can be used to flag or fail builds if component licenses conflict or if a component is used against policy. 
  • Component identification tools—component inventory tools designed to create a software bill-of-material (SBOM). These tools are useful for officially declaring what components are included in a project. 


Open source licensing is complex and can be difficult to understand. However, to ensure compliance it is necessary to properly use open source licenses. Depending on the number of components you introduce into your codebase, you may want to use either manual or semi-automatic methods. 

If you use a lot of different software components, manual compliance execution may not be practical. In this case, you can use file scanners, code scanners, and other available tooling. Use whichever method works for you, but do check your code and ensure all components comply with license usage rights.

Previous Story Stories that shaped Fresno State's spring semester article thumbnail mt-3

Stories that shaped Fresno State's spring semester

Next Story Fresno State NAACP gather thousands to protest the death of George Floyd article thumbnail mt-3

Fresno State NAACP gather thousands to protest the death of George Floyd